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 nicolas.cellier.aka.nice@gmail.com 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 Das.Linux@gmx.de a écrit :
On 29.04.2020, at 21:36, Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com> 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
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 Am 29.04.2020 23:03:23 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: 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 <Das.Linux@gmx.de [mailto:Das.Linux@gmx.de]> a écrit :
On 29.04.2020, at 21:36, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com [mailto:nicolas.cellier.aka.nice@gmail.com]> 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 [http://www.squeaksource.com//MetacelloRepository]). Of course, we could change that with Installer metacello repository: 'http://foobar.com [http://foobar.com]' etc...
Because that would essentially be Metcallo itself.
Try it:
Metacello new configuration: 'Xtreams'; version: #stable; load
Best regards -Tobias
On 30.04.2020, at 09:49, Marcel Taeumel marcel.taeumel@hpi.de 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 Am 30.04.2020 10:13:07 schrieb Tobias Pape das.linux@gmx.de:
On 30.04.2020, at 09:49, Marcel Taeumel 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
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 Am 30.04.2020 10:18:08 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
... 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 Am 30.04.2020 10:13:07 schrieb Tobias Pape das.linux@gmx.de:
On 30.04.2020, at 09:49, Marcel Taeumel 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
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 Am 30.04.2020 10:21:06 schrieb Marcel Taeumel marcel.taeumel@hpi.de: 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 Am 30.04.2020 10:18:08 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
... 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 Am 30.04.2020 10:13:07 schrieb Tobias Pape das.linux@gmx.de:
On 30.04.2020, at 09:49, Marcel Taeumel 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
On 30.04.2020, at 10:21, Marcel Taeumel marcel.taeumel@hpi.de 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 Am 30.04.2020 10:54:43 schrieb Tobias Pape das.linux@gmx.de:
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
On 30.04.2020, at 10:57, Marcel Taeumel marcel.taeumel@hpi.de 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 Am 30.04.2020 11:00:41 schrieb Tobias Pape das.linux@gmx.de:
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
On 30.04.2020, at 11:21, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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 Am 30.04.2020 11:36:50 schrieb Tobias Pape das.linux@gmx.de:
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
Hi
On 30.04.2020, at 12:37, Marcel Taeumel marcel.taeumel@hpi.de 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
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 marcel.taeumel@hpi.de:
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 das.linux@gmx.de:
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 Am 30.04.2020 13:01:54 schrieb Jakob Reschke forums.jakob@resfarm.de: 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
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 marcel.taeumel@hpi.de:
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 forums.jakob@resfarm.de:
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
+1
/—————————————————————/ For encrypted mail use jgpfersich@protonmail.com - Free account at ProtonMail.com Web: https://objectnets.net and https://objectnets.org https://datascilv.com https://datascilv.org
On Apr 30, 2020, at 04:02, Jakob Reschke forums.jakob@resfarm.de wrote:
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/
On Thu, Apr 30, 2020 at 12:37:30PM +0200, Marcel Taeumel 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"
<OT>
Regardless of the outcome of this discussion, please note that Metacello should not be used to install OSProcess/CommandShell. Nothing against Metacello, it is just not appropriate for this case.
Thanks, Dave
</OT>
Appropriate is whatever the maintainer chose it to be. Except if it was a bad choice. Then your only chance is to become a maintainer. :-)
David T. Lewis lewis@mail.msen.com schrieb am Do., 30. Apr. 2020, 20:55:
On Thu, Apr 30, 2020 at 12:37:30PM +0200, Marcel Taeumel 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"
<OT>
Regardless of the outcome of this discussion, please note that Metacello should not be used to install OSProcess/CommandShell. Nothing against Metacello, it is just not appropriate for this case.
Thanks, Dave
</OT>
On 2020-04-30, at 1:57 AM, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Not enough sense to come in out of the rain.
Wait, what, who pressed that button?
Anyway - a side issue relating to this discussion. Project names and class names; hint - they don't need to be the same!
A user level class for accessing OojamwigglePlus project facilities doe NOT need to be named something utterly unguessable nor longwindedly projectname+moreverbiage.
Metacello may well be a great project etc etc but it's not the most obvious thing to lok for when you're wanting to use an installer to install some code. That might be sometihng named, ooh, maybe "installer" ?
On 2020-04-30, at 9:55 AM, tim Rowledge tim@rowledge.org wrote:
On 2020-04-30, at 1:57 AM, Marcel Taeumel marcel.taeumel@hpi.de 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, amongst other things, why we have HostWindow* instead of AriethffaFenestriWindowProxy etc.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A sad tale that brings a lump to the eye and a tear to the throat.
On 30.04.2020, at 20:04, tim Rowledge tim@rowledge.org wrote:
Wait, what, who pressed that button?
Anyway - a side issue relating to this discussion. Project names and class names; hint - they don't need to be the same!
A user level class for accessing OojamwigglePlus project facilities doe NOT need to be named something utterly unguessable nor longwindedly projectname+moreverbiage.
Metacello may well be a great project etc etc but it's not the most obvious thing to lok for when you're wanting to use an installer to install some code. That might be sometihng named, ooh, maybe "installer" ?
On 2020-04-30, at 9:55 AM, tim Rowledge tim@rowledge.org wrote:
On 2020-04-30, at 1:57 AM, Marcel Taeumel marcel.taeumel@hpi.de 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, amongst other things, why we have HostWindow* instead of AriethffaFenestriWindowProxy etc.
If it was named Installer on GS/Pharo/Cuis too, then yes. Otherwise, firm No.
Best regards -Tobias
On 30.04.2020, at 10:18, Marcel Taeumel marcel.taeumel@hpi.de 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
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Jakob Reschke -
John Pfersich -
Marcel Taeumel -
Nicolas Cellier -
tim Rowledge -
Tobias Pape