[Pharo-project] Policy for storing metacello configurations
I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent. Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦). Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us. Cheers, Max
On 17 August 2011 08:59, Max Leske <maxleske@gmail.com> wrote:
Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦).
The MetacelloConfiguration belongs to the project and is under responsibility of the developers, so one should be in the project's repo. MetacelloRepository is the central well-known place, so maybe only versions with a stable release really need to be there? There will be other well-known places, the idea is to have a curated one for each version of Pharo I believe. In any case, maybe part of this should be docuplemented into MetacelloToolBox ? (PS. toolbox is a proper english word, so that capital B in the class name is unnecessary :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Damien, Stef and I are going to talk at ESUG about the procedures/recommendations/tools for managing configurations in Pharo. I (almost) apologize for naming the class MetacelloToolBox, but what do you expect from a person who makes up names all the time? With project names like Metacello or tODE and a blog called '(gem)Stone Soup' it's not always clear whether I'm making a mistake or a statement:) Dale ----- Original Message ----- | From: "Damien Pollet" <damien.pollet@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 12:56:10 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | On 17 August 2011 08:59, Max Leske <maxleske@gmail.com> wrote: | > Some people seem to have adopted MetacelloRepository as the | > standard repository for all configurations, others keep the | > configuration for a project in the project repositories and a | > third group uses both repositories (where one repository contains | > outdated versions of courseâ¦). | | The MetacelloConfiguration belongs to the project and is under | responsibility of the developers, so one should be in the project's | repo. | | MetacelloRepository is the central well-known place, so maybe only | versions with a stable release really need to be there? | | There will be other well-known places, the idea is to have a curated | one for each version of Pharo I believe. | | In any case, maybe part of this should be docuplemented into | MetacelloToolBox ? | | (PS. toolbox is a proper english word, so that capital B in the class | name is unnecessary :) | -- | Damien Pollet | type less, do more [ | ] http://people.untyped.org/damien.pollet | |
On 17 August 2011 19:04, Dale Henrichs <dhenrich@vmware.com> wrote:
Stef and I are going to talk at ESUG about the procedures/recommendations/tools for managing configurations in Pharo.
Cool, I'm interested too (though probably to obsessive-compulsive to have a useful point of view)
I (almost) apologize for naming the class MetacelloToolBox, but what do you expect from a person who makes up names all the time? With project names like Metacello or tODE and a blog called '(gem)Stone Soup' it's not always clear whether I'm making a mistake or a statement:)
MetacelloToolRectangleMorph. That would have been a statement :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Damien and others, I am hoping to have a set of relatively informal discussions of "Metacello and collaboration" on Saturday and Sunday at Camp Smalltalk with additional discussions throughout the week. I'll send mail to the Metacello mailing list[1] and tweet[2] about times and locations, which might end up being "meet now at the table in the lobby":). I'll also try to take notes and share info on the mailing list... If you have ideas and opinions I'm interested in hearing them, so come one up to me if the time is right we'll start an impromptu discussion group. If you won't be attending ESUG, then now would be a good time to send mail to the Metacello mailing list with your ideas and we can use them as topic in the discussions ... Dale [1] http://groups.google.com/group/metacello/ [2] http://twitter.com/#!/metacello ----- Original Message ----- | From: "Damien Pollet" <damien.pollet@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 10:34:06 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | On 17 August 2011 19:04, Dale Henrichs <dhenrich@vmware.com> wrote: | > Stef and I are going to talk at ESUG about the | > procedures/recommendations/tools for managing configurations in | > Pharo. | | Cool, I'm interested too (though probably to obsessive-compulsive to | have a useful point of view) | | > I (almost) apologize for naming the class MetacelloToolBox, but | > what do you expect from a person who makes up names all the time? | > With project names like Metacello or tODE and a blog called | > '(gem)Stone Soup' it's not always clear whether I'm making a | > mistake or a statement:) | | MetacelloToolRectangleMorph. That would have been a statement :) | | -- | Damien Pollet | type less, do more [ | ] http://people.untyped.org/damien.pollet | |
Dale, To finally answer your question about the concerning configurations: they were both outdated (although they also had critical warnings). Max On 17.08.2011, at 20:57, Dale Henrichs wrote:
Damien and others,
I am hoping to have a set of relatively informal discussions of "Metacello and collaboration" on Saturday and Sunday at Camp Smalltalk with additional discussions throughout the week.
I'll send mail to the Metacello mailing list[1] and tweet[2] about times and locations, which might end up being "meet now at the table in the lobby":). I'll also try to take notes and share info on the mailing list...
If you have ideas and opinions I'm interested in hearing them, so come one up to me if the time is right we'll start an impromptu discussion group.
If you won't be attending ESUG, then now would be a good time to send mail to the Metacello mailing list with your ideas and we can use them as topic in the discussions ...
Dale
[1] http://groups.google.com/group/metacello/ [2] http://twitter.com/#!/metacello
----- Original Message ----- | From: "Damien Pollet" <damien.pollet@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 10:34:06 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | On 17 August 2011 19:04, Dale Henrichs <dhenrich@vmware.com> wrote: | > Stef and I are going to talk at ESUG about the | > procedures/recommendations/tools for managing configurations in | > Pharo. | | Cool, I'm interested too (though probably to obsessive-compulsive to | have a useful point of view) | | > I (almost) apologize for naming the class MetacelloToolBox, but | > what do you expect from a person who makes up names all the time? | > With project names like Metacello or tODE and a blog called | > '(gem)Stone Soup' it's not always clear whether I'm making a | > mistake or a statement:) | | MetacelloToolRectangleMorph. That would have been a statement :) | | -- | Damien Pollet | type less, do more [ | ] http://people.untyped.org/damien.pollet | |
Max, You have reason to complain... Not all projects use Metacello so there are still cases where the configuration is only found in the MetacelloRepository. Sometimes developers forget to copy the configurations to the MetacelloRepository. And so on.... In self defense: 1. Use the configuration found in the project repository. 2. Use the configuration found in MetacelloRepository If there are configs in both places and they are not in synch, contact the project maintainers and let them know. If you want to _know_ which config file is later (and whether or not they are even related), you can look at the history for both files and compare UUIDs or find a common ancestor based on UUID. Examining the ancestry of a version is the only way to know how two different mcz relate to one another. If you have two mcz files with a common ancestor, you are still confronted by a dilemma as to which one should you use.... With all that said, I am interested in knowing what was "wrong" with the configurations. Were they two unrelated branches of a configuration or was one configuration way out of date with respect to the other, or??? I'm asking because from a Metacello perspective once a Metacello version is released it should never be changed and that means that for released versions it doesn't matter whether or not you are using the latest configuration, unless the configurations are way out of date. If you are usinga Metacello version that is still under #development then it does matter whether or not you are using the latest configuration. Dale ----- Original Message ----- | From: "Max Leske" <maxleske@gmail.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Tuesday, August 16, 2011 11:59:59 PM | Subject: [Pharo-project] Policy for storing metacello configurations | | I would like to complain a bit about the current way Metacello | configurations are distributed in different repositories. I ended up | using the wrong configuration for two different projects twice in | just two days. Apart from the date in the configuration file (and | possibly the version number, although that's not as reliable) | there's no easy way to tell which configuration is the most recent. | | Some people seem to have adopted MetacelloRepository as the standard | repository for all configurations, others keep the configuration for | a project in the project repositories and a third group uses both | repositories (where one repository contains outdated versions of | courseâ¦). | | Can we please agree on a simple policy on where to store the | configuration for a project? I am sure that this would make life | easier for all of us. | | Cheers, | Max |
 1. Use the configuration found in the project repository.  2. Use the configuration found in MetacelloRepository
The following code would do that automatically (i.e. for Moose): Gofer new squeaksource: 'Moose'; squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault Lukas -- Lukas Renggli www.lukas-renggli.ch
The policy should be - put a configurationOf in your package - publish when you want a copy of it in metacellorepository I will sit with dale sunday because we want the "publish" to copy all the dependent package also in the DistributionMetacelloRepository On Aug 17, 2011, at 8:59 AM, Max Leske wrote:
I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent.
Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦).
Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us.
Cheers, Max
Maybe a bit of wishful thinking but⦠Ideally, I think of the metacellorepository as a kind of 'smart folder' where all metacello configurations of public repositories are automatically included. Something like a smart mail folder on mac mail. Having two locations with the same package almost always leads to confusion / mistakes / forgetting / etc⦠Would such an 'automatic' repository be possible to implement in squeaksource3 and/or smalltalk hub? Johan On 17 Aug 2011, at 20:01, Stéphane Ducasse wrote:
The policy should be - put a configurationOf in your package - publish when you want a copy of it in metacellorepository
I will sit with dale sunday because we want the "publish" to copy all the dependent package also in the DistributionMetacelloRepository
On Aug 17, 2011, at 8:59 AM, Max Leske wrote:
I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent.
Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦).
Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us.
Cheers, Max
I'm not sure whether this is one of the goals of the community or whether maybe someone's already heading in this direction, but something like Gofer install: #myPackage that looked up which repo and version are the suitable ones would really rock big time. The apt-get of Pharo, call it... To go on with the apt metaphor, Gofer search: 'whatever' could return a list of packages the descriptions/names of which matched 'whatever'. What do you think? 2011/8/17 Johan Brichau <johan@inceptive.be>
Maybe a bit of wishful thinking butâ¦
Ideally, I think of the metacellorepository as a kind of 'smart folder' where all metacello configurations of public repositories are automatically included. Something like a smart mail folder on mac mail.
Having two locations with the same package almost always leads to confusion / mistakes / forgetting / etcâ¦
Would such an 'automatic' repository be possible to implement in squeaksource3 and/or smalltalk hub?
Johan
On 17 Aug 2011, at 20:01, Stéphane Ducasse wrote:
The policy should be - put a configurationOf in your package - publish when you want a copy of it in metacellorepository
I will sit with dale sunday because we want the "publish" to copy all the
dependent package also in the DistributionMetacelloRepository
On Aug 17, 2011, at 8:59 AM, Max Leske wrote:
I would like to complain a bit about the current way Metacello
configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent.
Some people seem to have adopted MetacelloRepository as the standard
repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦).
Can we please agree on a simple policy on where to store the
configuration for a project? I am sure that this would make life easier for all of us.
Cheers, Max
-- Bernat Romagosa.
Bernat, A while ago, Esteban Lorenzano released the GoferProjectLoader[1] that extends Gofer and allows one to load configurations. For example: Gofer project load: 'Seaside30'; load: 'Pier2'. loads the latest version of Seaside30 and then Pier2 ... there are options for further control ... By default 'Gofer project' looks in the MetacelloRepository, which works but right now subject to problems like the original complaint that started this thread... Stef and I will be talking about the process and implementation for "...looking up which repo and version are the suitable ones" so hopefully we'll come out of ESUG with a plan of action to take care of this problem... Dale [1] http://forum.world.st/ANN-Gofer-Project-Loader-1-0-BETA-td1596415.html ----- Original Message ----- | From: "Bernat Romagosa" <tibabenfortlapalanca@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 11:30:30 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | I'm not sure whether this is one of the goals of the community or | whether maybe someone's already heading in this direction, but | something like Gofer install: #myPackage that looked up which repo | and version are the suitable ones would really rock big time. The | apt-get of Pharo, call it... | | | To go on with the apt metaphor, Gofer search: 'whatever' could return | a list of packages the descriptions/names of which matched | 'whatever'. | | | What do you think? | | | | 2011/8/17 Johan Brichau < johan@inceptive.be > | | | Maybe a bit of wishful thinking but⦠| | Ideally, I think of the metacellorepository as a kind of 'smart | folder' where all metacello configurations of public repositories | are automatically included. | Something like a smart mail folder on mac mail. | | Having two locations with the same package almost always leads to | confusion / mistakes / forgetting / etc⦠| | Would such an 'automatic' repository be possible to implement in | squeaksource3 and/or smalltalk hub? | | Johan | | | | | On 17 Aug 2011, at 20:01, Stéphane Ducasse wrote: | | > | > The policy should be | > - put a configurationOf in your package | > - publish when you want a copy of it in metacellorepository | > | > I will sit with dale sunday because we want the "publish" to copy | > all the dependent package also in the | > DistributionMetacelloRepository | > | > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: | > | >> I would like to complain a bit about the current way Metacello | >> configurations are distributed in different repositories. I ended | >> up using the wrong configuration for two different projects twice | >> in just two days. Apart from the date in the configuration file | >> (and possibly the version number, although that's not as | >> reliable) there's no easy way to tell which configuration is the | >> most recent. | >> | >> Some people seem to have adopted MetacelloRepository as the | >> standard repository for all configurations, others keep the | >> configuration for a project in the project repositories and a | >> third group uses both repositories (where one repository contains | >> outdated versions of courseâ¦). | >> | >> Can we please agree on a simple policy on where to store the | >> configuration for a project? I am sure that this would make life | >> easier for all of us. | >> | >> Cheers, | >> Max | > | > | | | | | | | -- | Bernat Romagosa. |
Great, really! :) So, ideally we'd have ONE single config repo (MetacelloRepository), and Gofer project would look there, is that it? 2011/8/17 Dale Henrichs <dhenrich@vmware.com>
Bernat,
A while ago, Esteban Lorenzano released the GoferProjectLoader[1] that extends Gofer and allows one to load configurations. For example:
Gofer project load: 'Seaside30'; load: 'Pier2'.
loads the latest version of Seaside30 and then Pier2 ... there are options for further control ...
By default 'Gofer project' looks in the MetacelloRepository, which works but right now subject to problems like the original complaint that started this thread...
Stef and I will be talking about the process and implementation for "...looking up which repo and version are the suitable ones" so hopefully we'll come out of ESUG with a plan of action to take care of this problem...
Dale
[1] http://forum.world.st/ANN-Gofer-Project-Loader-1-0-BETA-td1596415.html
----- Original Message ----- | From: "Bernat Romagosa" <tibabenfortlapalanca@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 11:30:30 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | I'm not sure whether this is one of the goals of the community or | whether maybe someone's already heading in this direction, but | something like Gofer install: #myPackage that looked up which repo | and version are the suitable ones would really rock big time. The | apt-get of Pharo, call it... | | | To go on with the apt metaphor, Gofer search: 'whatever' could return | a list of packages the descriptions/names of which matched | 'whatever'. | | | What do you think? | | | | 2011/8/17 Johan Brichau < johan@inceptive.be > | | | Maybe a bit of wishful thinking but⦠| | Ideally, I think of the metacellorepository as a kind of 'smart | folder' where all metacello configurations of public repositories | are automatically included. | Something like a smart mail folder on mac mail. | | Having two locations with the same package almost always leads to | confusion / mistakes / forgetting / etc⦠| | Would such an 'automatic' repository be possible to implement in | squeaksource3 and/or smalltalk hub? | | Johan | | | | | On 17 Aug 2011, at 20:01, Stéphane Ducasse wrote: | | > | > The policy should be | > - put a configurationOf in your package | > - publish when you want a copy of it in metacellorepository | > | > I will sit with dale sunday because we want the "publish" to copy | > all the dependent package also in the | > DistributionMetacelloRepository | > | > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: | > | >> I would like to complain a bit about the current way Metacello | >> configurations are distributed in different repositories. I ended | >> up using the wrong configuration for two different projects twice | >> in just two days. Apart from the date in the configuration file | >> (and possibly the version number, although that's not as | >> reliable) there's no easy way to tell which configuration is the | >> most recent. | >> | >> Some people seem to have adopted MetacelloRepository as the | >> standard repository for all configurations, others keep the | >> configuration for a project in the project repositories and a | >> third group uses both repositories (where one repository contains | >> outdated versions of courseâ¦). | >> | >> Can we please agree on a simple policy on where to store the | >> configuration for a project? I am sure that this would make life | >> easier for all of us. | >> | >> Cheers, | >> Max | > | > | | | | | | | -- | Bernat Romagosa. |
-- Bernat Romagosa.
What I would like is that the published conf in the distro projects should get loaded, tests run.... automatically. Stef On Aug 17, 2011, at 8:14 PM, Johan Brichau wrote:
Maybe a bit of wishful thinking butâ¦
Ideally, I think of the metacellorepository as a kind of 'smart folder' where all metacello configurations of public repositories are automatically included. Something like a smart mail folder on mac mail.
Having two locations with the same package almost always leads to confusion / mistakes / forgetting / etcâ¦
Would such an 'automatic' repository be possible to implement in squeaksource3 and/or smalltalk hub?
Johan
On 17 Aug 2011, at 20:01, Stéphane Ducasse wrote:
The policy should be - put a configurationOf in your package - publish when you want a copy of it in metacellorepository
I will sit with dale sunday because we want the "publish" to copy all the dependent package also in the DistributionMetacelloRepository
On Aug 17, 2011, at 8:59 AM, Max Leske wrote:
I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent.
Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦).
Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us.
Cheers, Max
participants (7)
-
Bernat Romagosa -
Dale Henrichs -
Damien Pollet -
Johan Brichau -
Lukas Renggli -
Max Leske -
Stéphane Ducasse