Installer metacello
Locked
12
12
 
|
Hi all, I wonder why we haven't an InstallerMetacello flavour? We could write things like: Installer metacello configurationOf: 'Xtreams'; version: #stable; load. It would pick the Configuration in default repository (http://www.squeaksource.com//MetacelloRepository). Of course, we could change that with Installer metacello repository: 'http://foobar.com' etc... Any taker? |
|
|
> On 29.04.2020, at 21:36, Nicolas Cellier <[hidden email]> wrote: > > Hi all, > I wonder why we haven't an InstallerMetacello flavour? > We could write things like: > Installer metacello configurationOf: 'Xtreams'; version: #stable; load. > > It would pick the Configuration in default repository (http://www.squeaksource.com//MetacelloRepository). Of course, we could change that with Installer metacello repository: 'http://foobar.com' etc... Because that would essentially be Metcallo itself. Try it: Metacello new configuration: 'Xtreams'; version: #stable; load Best regards -Tobias |
|
|
Ah yes OK, I thought it could ensureRecentMetacello, but I see that MetacelloStub is doing that... Le mer. 29 avr. 2020 à 22:06, Tobias Pape <[hidden email]> a écrit :
|
|
> Because that would essentially be Metcallo itself. I think an additional way through the Installer protocol wouldn't hurt. Maybe "Installer metacello" could just return "Metacello new". Or directly map the #install call to Metacello in a custom InstallerMetacello as suggested: Installer metacello "returns a new InstallerMetacello" package: 'Xtreams'; "maps auto-magically to ConfigurationOfXtreams" install. Best, Marcel
|
|
|
> On 30.04.2020, at 09:49, Marcel Taeumel <[hidden email]> wrote: > > > Because that would essentially be Metcallo itself. > > I think an additional way through the Installer protocol wouldn't hurt. Maybe "Installer metacello" could just return "Metacello new". Or directly map the #install call to Metacello in a custom InstallerMetacello as suggested: > > Installer metacello "returns a new InstallerMetacello" > package: 'Xtreams'; "maps auto-magically to ConfigurationOfXtreams" > install. I'd really like to _not_ have that. The very point of Metacello is that you can say "Metacello new ..." on GemStone AND Squeak AND Pharo AND ... and having multiple, platformspecific ways really is against that spirit. Best regards -Tobias |
|
|
> ... having multiple, platformspecific ways really is against that spirit. So, in the long term, you want to get rid of Installer? Well, either that or fill it up to the current state of things. I did not argue that those Installer calls should be used in a cross-dialect setting. But it would help building things such as the PreferenceWizard. Best, Marcel
|
|
|
Installer can become a great starting point for code and resource loading for all kinds of local experiments. Including file-in from the file system. It might already be: Installer class >> installFile:. So, Installer is at a different abstraction level and has different use cases compared to Metacello. Best, Marcel
|
|
|
Aaaand: Metacello is an external dependency. Installer can provide fall-back strategies if that dependency is not available such as good error messages or alternative code locations. Metacello should be the way to go in CI and alike. But Installer is better for in-image tooling. Installer could be the object that offers the user: "Do you just want to install this project via Metacello or do you want to install the Git Browser to start working on that project?" Just my two cents. :-) Best, Marcel
|
|
|
In reply to this post by marcel.taeumel
> On 30.04.2020, at 10:18, Marcel Taeumel <[hidden email]> wrote: > > > ... having multiple, platformspecific ways really is against that spirit. > > So, in the long term, you want to get rid of Installer? Installer and Metacello should not mix. ATM I don't think Installer should go away. But it is actually too vague to be used beyond a makeshift Monticello API in everyday use (I know of #merge:; I personally do not like it). > Well, either that or fill it up to the current state of things. I did not argue that those Installer calls should be used in a cross-dialect setting. True. But Metacello is. Saying "Everywhere, you typically use 'Metacello new'. Oh, but in Squeak, people use 'Installer metacello' with a different API" is IMHO the wrong direction. > But it would help building things such as the PreferenceWizard. Software configuration management does not really sound like a place for a Preferences Wizard ;) I think we should learn from Cuis here… Best regards -Tobias |
|
|
In reply to this post by marcel.taeumel
> On 30.04.2020, at 10:21, Marcel Taeumel <[hidden email]> wrote: > > Installer can become a great starting point for code and resource loading for all kinds of local experiments. Including file-in from the file system. It might already be: Installer class >> installFile:. > > So, Installer is at a different abstraction level and has different use cases compared to Metacello. Seems like it, but it ultimately waters down and mixes installations of different abstractions. That is probably wrong. For me, Installer currently is not more than a shim atop Monticello. All other usecases of it have either vanished or are better expressed declaratively (as in Metacello). Best regards -Tobias |
|
|
Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-) Best, Marcel
|
|
|
> On 30.04.2020, at 10:57, Marcel Taeumel <[hidden email]> wrote: > > Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-) This is its disadvantage: it means too many different things to different people at different levels. I hold that it is _not_ descriptive in that way :) I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. Best regards -Tobias |
|
|
> I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. From a generic Smalltalk perspective, sure. But that's not the role of Installer here. :-) Let's discuss it in a Squeak-specific way: Installer vs. SqueakMap, it is then. Metacello should not be part of that discussion. It is an external project not within the control of the Squeak community. Still, compatibility is very important. It is just a different discussion. Still +1 for InstallerMetacello. Best, Marcel
|
|
|
> On 30.04.2020, at 11:21, Marcel Taeumel <[hidden email]> wrote: > > > I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. > > From a generic Smalltalk perspective, sure. But that's not the role of Installer here. :-) Let's discuss it in a Squeak-specific way: Installer vs. SqueakMap, it is then. Metacello should not be part of that discussion. It is an external project not within the control of the Squeak community. Still, compatibility is very important. It is just a different discussion. > > Still +1 for InstallerMetacello. I don't get it then. Why Installer vs Squeakmap but then +1 for InstallerMetacello? I specifically do not want more than one method to install Metacello projects. -1 Best regards -Tobias > > Best, > Marcel >> Am 30.04.2020 11:00:41 schrieb Tobias Pape <[hidden email]>: >> >> >> > On 30.04.2020, at 10:57, Marcel Taeumel wrote: >> > >> > Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-) >> >> This is its disadvantage: it means too many different things to different people at different levels. >> I hold that it is _not_ descriptive in that way :) >> >> I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. >> >> >> Best regards >> -Tobias >> > |
|
|
Let's make it more concrete. I prefer sprinkle "Installer ..." calls in the system compared to "Metacello new". Here are some examples: - Adding a menu entry to the world menu such as "Git browser (click to install)" - Adding a list entry to the preferences wizard's "install extra packages" page such as "installOSProcess" Here is why. Installer might be just a shell to get things going; not a fully-fledged package-dependency manager. However, it can act as a nice little facade to mitigate future trade-offs. To integrate different package-dependency managers such as Monticello and Metacello for now. We need a nice place to answer the request "How can I install stuff?". Metacello is too low-level for that. So is Monticello. SqueakMap and Installer are more suited to deal with this. And they can act as thin layers above the actual dependency managers. Maybe add extra bells and whistles (e.g. convenient one-liner, screeshots, ...) -- but only to improve the user experience. Best, Marcel
|
|
|
Hi
> On 30.04.2020, at 12:37, Marcel Taeumel <[hidden email]> wrote: > > Let's make it more concrete. I prefer sprinkle "Installer ..." calls in the system compared to "Metacello new". Here are some examples: > > - Adding a menu entry to the world menu such as "Git browser (click to install)" > - Adding a list entry to the preferences wizard's "install extra packages" page such as "installOSProcess" > > Here is why. Installer might be just a shell to get things going; not a fully-fledged package-dependency manager. However, it can act as a nice little facade to mitigate future trade-offs. To integrate different package-dependency managers such as Monticello and Metacello for now. > > We need a nice place to answer the request "How can I install stuff?". Metacello is too low-level for that. So is Monticello. SqueakMap and Installer are more suited to deal with this. And they can act as thin layers above the actual dependency managers. Maybe add extra bells and whistles (e.g. convenient one-liner, screeshots, ...) -- but only to improve the user experience. I disagree. -t |
|
|
In reply to this post by marcel.taeumel
What does this facade buy us? How a software gets installed in the
image is software-specific unless you want to dictate a solution. We could create SqueakMap entries for all things that have an install button in the Trunk, but that entry would also just contain Metacello new ... When a piece of software changes its install or dependency management solution, you do not really want to maintain the facade in addition to the actual change, do you? It would be more straightforward to just change what this particular install button does. I see nothing to be gained from a common API for distinct dependency management models (i. e., there is not really any integration) https://xkcd.com/927/ Kind regards, Jakob Am Do., 30. Apr. 2020 um 12:37 Uhr schrieb Marcel Taeumel <[hidden email]>: > > Let's make it more concrete. I prefer sprinkle "Installer ..." calls in the system compared to "Metacello new". Here are some examples: > > - Adding a menu entry to the world menu such as "Git browser (click to install)" > - Adding a list entry to the preferences wizard's "install extra packages" page such as "installOSProcess" > > Here is why. Installer might be just a shell to get things going; not a fully-fledged package-dependency manager. However, it can act as a nice little facade to mitigate future trade-offs. To integrate different package-dependency managers such as Monticello and Metacello for now. > > We need a nice place to answer the request "How can I install stuff?". Metacello is too low-level for that. So is Monticello. SqueakMap and Installer are more suited to deal with this. And they can act as thin layers above the actual dependency managers. Maybe add extra bells and whistles (e.g. convenient one-liner, screeshots, ...) -- but only to improve the user experience. > > Best, > Marcel > > Am 30.04.2020 11:36:50 schrieb Tobias Pape <[hidden email]>: > > > > On 30.04.2020, at 11:21, Marcel Taeumel wrote: > > > > > I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. > > > > From a generic Smalltalk perspective, sure. But that's not the role of Installer here. :-) Let's discuss it in a Squeak-specific way: Installer vs. SqueakMap, it is then. Metacello should not be part of that discussion. It is an external project not within the control of the Squeak community. Still, compatibility is very important. It is just a different discussion. > > > > Still +1 for InstallerMetacello. > > I don't get it then. Why Installer vs Squeakmap but then +1 for InstallerMetacello? > > I specifically do not want more than one method to install Metacello projects. > -1 > > Best regards > -Tobias > > > > > Best, > > Marcel > >> Am 30.04.2020 11:00:41 schrieb Tobias Pape : > >> > >> > >> > On 30.04.2020, at 10:57, Marcel Taeumel wrote: > >> > > >> > Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-) > >> > >> This is its disadvantage: it means too many different things to different people at different levels. > >> I hold that it is _not_ descriptive in that way :) > >> > >> I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. > >> > >> > >> Best regards > >> -Tobias > >> > > > > > > |
|
|
Thanks Jakob! Finally someone who reacts to the actual arguments I am trying to make. :-) Yes, such a facade would have to be managed. Yet, it is already there. We should decide for at least one direction. Not adding InstallerMetacello for this reason indicates getting rid of Installer in the long run. Existing stuff might be moved from Installer to a Monti(!)cello class. To at least level the field. Best, Marcel
|
|
|
Note that Monticello scripting via Installer targets the same niche
that Gofer fills already (it is used under the hood of Metacello). So there might be no need to move something to Monticello. Just use Gofer, unless Installer can do something here that Gofer can't? Am Do., 30. Apr. 2020 um 15:24 Uhr schrieb Marcel Taeumel <[hidden email]>: > > Thanks Jakob! Finally someone who reacts to the actual arguments I am trying to make. :-) > > Yes, such a facade would have to be managed. Yet, it is already there. We should decide for at least one direction. Not adding InstallerMetacello for this reason indicates getting rid of Installer in the long run. Existing stuff might be moved from Installer to a Monti(!)cello class. To at least level the field. > > Best, > Marcel > > Am 30.04.2020 13:01:54 schrieb Jakob Reschke <[hidden email]>: > > What does this facade buy us? How a software gets installed in the > image is software-specific unless you want to dictate a solution. We > could create SqueakMap entries for all things that have an install > button in the Trunk, but that entry would also just contain Metacello > new ... > > When a piece of software changes its install or dependency management > solution, you do not really want to maintain the facade in addition to > the actual change, do you? It would be more straightforward to just > change what this particular install button does. > > I see nothing to be gained from a common API for distinct dependency > management models (i. e., there is not really any integration) > https://xkcd.com/927/ > > Kind regards, > Jakob > > Am Do., 30. Apr. 2020 um 12:37 Uhr schrieb Marcel Taeumel > : > > > > Let's make it more concrete. I prefer sprinkle "Installer ..." calls in the system compared to "Metacello new". Here are some examples: > > > > - Adding a menu entry to the world menu such as "Git browser (click to install)" > > - Adding a list entry to the preferences wizard's "install extra packages" page such as "installOSProcess" > > > > Here is why. Installer might be just a shell to get things going; not a fully-fledged package-dependency manager. However, it can act as a nice little facade to mitigate future trade-offs. To integrate different package-dependency managers such as Monticello and Metacello for now. > > > > We need a nice place to answer the request "How can I install stuff?". Metacello is too low-level for that. So is Monticello. SqueakMap and Installer are more suited to deal with this. And they can act as thin layers above the actual dependency managers. Maybe add extra bells and whistles (e.g. convenient one-liner, screeshots, ...) -- but only to improve the user experience. > > > > Best, > > Marcel > > > > Am 30.04.2020 11:36:50 schrieb Tobias Pape : > > > > > > > On 30.04.2020, at 11:21, Marcel Taeumel wrote: > > > > > > > I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. > > > > > > From a generic Smalltalk perspective, sure. But that's not the role of Installer here. :-) Let's discuss it in a Squeak-specific way: Installer vs. SqueakMap, it is then. Metacello should not be part of that discussion. It is an external project not within the control of the Squeak community. Still, compatibility is very important. It is just a different discussion. > > > > > > Still +1 for InstallerMetacello. > > > > I don't get it then. Why Installer vs Squeakmap but then +1 for InstallerMetacello? > > > > I specifically do not want more than one method to install Metacello projects. > > -1 > > > > Best regards > > -Tobias > > > > > > > > Best, > > > Marcel > > >> Am 30.04.2020 11:00:41 schrieb Tobias Pape : > > >> > > >> > > >> > On 30.04.2020, at 10:57, Marcel Taeumel wrote: > > >> > > > >> > Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-) > > >> > > >> This is its disadvantage: it means too many different things to different people at different levels. > > >> I hold that it is _not_ descriptive in that way :) > > >> > > >> I think: If you want to use new Smalltalk software via Metacello, use "Metacello new ...", regardless of the Smalltalk you're using. > > >> > > >> > > >> Best regards > > >> -Tobias > > >> > > > > > > > > > > > > > |
|
|
In reply to this post by marcel.taeumel
> On 2020-04-30, at 1:57 AM, Marcel Taeumel <[hidden email]> wrote: > > Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-) > > Best, > Marcel >> Am 30.04.2020 10:54:43 schrieb Tobias Pape <[hidden email]>: >> >> >> > On 30.04.2020, at 10:21, Marcel Taeumel wrote: >> > >> > Installer can become a great starting point for code and resource loading for all kinds of local experiments. Including file-in from the file system. It might already be: Installer class >> installFile:. >> > >> > So, Installer is at a different abstraction level and has different use cases compared to Metacello. >> >> Seems like it, but it ultimately waters down and mixes installations of different abstractions. >> That is probably wrong. >> >> For me, Installer currently is not more than a shim atop Monticello. All other usecases of it have either vanished or are better expressed declaratively (as in Metacello). >> >> Best regards >> -Tobias >> >> > tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Not enough sense to come in out of the rain. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |