Here is yet another way how we could model universes. We just have multiple Metacello repositories: - MetacelloRepository is the one that everybody can commit to (testing universe) - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 - etc. A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed. This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality. Cheers, Adrian On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote:

El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió:

...

----- "Esteban Lorenzano" <estebanlm@gmail.com> wrote:

| > - any idea about how we go to differentiate "stable" and "unstable" | | > universes for each Pharo version? How does the user know which version | > is the one he needs for his version of Pharo? Sorry, this is not | > directly related to the Gofer Project Loader but I think it is the next | > important step towards a working package management system! | | No clue... maybe we need to add to Metacello a new "dependence | dimension", like "minimum version of distribution"... but Dale can be | much more helpful than me in this area.

I imagine that code targetted for specific Pharo versions will be treated like we treat code targeted for different Smalltalk dialects. So you would write specs like the following:

spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...].

or possibly like the following, if a finer version granularity is needed:

spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.0-10508' do: [...]. spec for: #'pharo1.0-10515' do: [...]. spec for: #'pharo1.1' do: [...]. spec for: #'pharo1.1-11508' do: [...]. spec for: #'pharo1.1-11515' do: [...].

Dale

umm, no please!

There would be a lot of combinations after a while.

Why about having a new spec universes message that accept a list of symbols, each symbol representing a given "universe" of tested packages. This list will be the only thing to modify when grouping different versions of the same package in different repositories.

For example, I start with ConfigurationOfMagma version 1.0r43. Two weeks later I release ConfigurationOfMagma with support for loading 1.0r44. Both this versions have been tested on Pharo 1.0. So the both are marked

spec universes: #(#pharo10).

A week later Pharo 1.1 is released, and I test the configuration on this new version of pharo. Both work ok. So I modify the line to:

spec universes: #(#pharo10 #pharo11)

and commit.

The tools (GoferProjectLoader) then add functionality to scan this list and presents the users only the appropriated ones based on the image the users is querying the repository.

Of course this is very simplistic because as the debian model shows, requires a maintainer of each configuration and the user to report if a given #pharo11 marked version actually doesn't work. If something don't work, or a new version is given that works, or the tag #pharo11 is removed from that version effectively removing it from that given universe until bugs are fixed or worked around.

What do you think?

Cheers

...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Okay, I think I am wrapping my brain around this discussion...Sometimes I can be very thick headed:) Yes that makes perfect sense ... I was thinking about a different issue (code that can only run in Pharo1.1 for example) ... And the Gofer Project Loader is the perfect place to manage this...independently of Metacello ... Yes! Dale ----- "Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote: | On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote: | | > Here is yet another way how we could model universes. We just have | multiple Metacello repositories: | > | > - MetacelloRepository is the one that everybody can commit to | (testing universe) | > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 | > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 | > - etc. | | Yes this is what I was thinking. | In general the policy for a metacello config is to be in the project | where it belongsto and **copied** to the MetacelloRepository. | | > A package always first gets into the testing universe and when it is | known to work in a particular version it is copied into the | appropriate repository. The Gofer Project Loader would just need to | know the repository for the current Pharo version. Like in Debian, one | can add the testing universe to get unstable versions if needed. | > | > This setup would not need any code changes in Metacello and it | allows us to use access rights to assign people to manage the process | and assert a certain level of quality. | | Yes! | | > | > Cheers, | > Adrian | > | > | > On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote: | > | >> El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió: | >>> ----- "Esteban Lorenzano" <estebanlm@gmail.com> wrote: | >>> | >>> | > - any idea about how we go to differentiate "stable" and | "unstable" | >>> | | >>> | > universes for each Pharo version? How does the user know which | version | >>> | > is the one he needs for his version of Pharo? Sorry, this is | not | >>> | > directly related to the Gofer Project Loader but I think it is | the next | >>> | > important step towards a working package management system! | >>> | | >>> | No clue... maybe we need to add to Metacello a new "dependence | >>> | dimension", like "minimum version of distribution"... but Dale | can be | >>> | much more helpful than me in this area. | >>> | >>> I imagine that code targetted for specific Pharo versions will be | treated like we treat code targeted for different Smalltalk dialects. | So you would write specs like the following: | >>> | >>> spec for: #common do: [...]. | >>> spec for: #squeakCommon do: [...]. | >>> spec for: #pharo do: [...]. | >>> spec for: #'pharo1.0' do: [...]. | >>> spec for: #'pharo1.1' do: [...]. | >>> | >>> or possibly like the following, if a finer version granularity is | needed: | >>> | >>> spec for: #common do: [...]. | >>> spec for: #squeakCommon do: [...]. | >>> spec for: #pharo do: [...]. | >>> spec for: #'pharo1.0' do: [...]. | >>> spec for: #'pharo1.0-10508' do: [...]. | >>> spec for: #'pharo1.0-10515' do: [...]. | >>> spec for: #'pharo1.1' do: [...]. | >>> spec for: #'pharo1.1-11508' do: [...]. | >>> spec for: #'pharo1.1-11515' do: [...]. | >>> | >>> Dale | >>> | >> | >> umm, no please! | >> | >> There would be a lot of combinations after a while. | >> | >> Why about having a new spec universes message that accept a list | of | >> symbols, each symbol representing a given "universe" of tested | packages. | >> This list will be the only thing to modify when grouping different | >> versions of the same package in different repositories. | >> | >> For example, I start with ConfigurationOfMagma version 1.0r43. Two | weeks | >> later I release ConfigurationOfMagma with support for loading | 1.0r44. | >> Both this versions have been tested on Pharo 1.0. So the both are | >> marked | >> | >> spec universes: #(#pharo10). | >> | >> A week later Pharo 1.1 is released, and I test the configuration on | this | >> new version of pharo. Both work ok. So I modify the line to: | >> | >> spec universes: #(#pharo10 #pharo11) | >> | >> and commit. | >> | >> The tools (GoferProjectLoader) then add functionality to scan this | list | >> and presents the users only the appropriated ones based on the | image the | >> users is querying the repository. | >> | >> Of course this is very simplistic because as the debian model | shows, | >> requires a maintainer of each configuration and the user to report | if a | >> given #pharo11 marked version actually doesn't work. If something | don't | >> work, or a new version is given that works, or the tag #pharo11 is | >> removed from that version effectively removing it from that given | >> universe until bugs are fixed or worked around. | >> | >> What do you think? | >> | >> Cheers | >>> _______________________________________________ | >>> Pharo-project mailing list | >>> Pharo-project@lists.gforge.inria.fr | >>> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >> | >> -- | >> Miguel Cobá | >> http://miguel.leugim.com.mx | >> | >> | >> _______________________________________________ | >> Pharo-project mailing list | >> Pharo-project@lists.gforge.inria.fr | >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Looks like GoferProjectLoader class>>createRepositories is the place to start... Dale ----- "Adrian Lienhard" <adi@netstyle.ch> wrote: | ok, cool, then lets try to do it this way! | | Estaban, how can we make Gofer Project Loader to be initialized with | MetacelloRepositoryPharo1.0 in a Pharo 1.0 image and the other | repository in 1.1 etc.? | | Cheers, | Adrian | | On Mar 18, 2010, at 18:14 , Dale Henrichs wrote: | | > Okay, | > | > I think I am wrapping my brain around this discussion...Sometimes I | can be very thick headed:) | > | > Yes that makes perfect sense ... I was thinking about a different | issue (code that can only run in Pharo1.1 for example) ... | > | > And the Gofer Project Loader is the perfect place to manage | this...independently of Metacello ... Yes! | > | > Dale | > ----- "Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote: | > | > | On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote: | > | | > | > Here is yet another way how we could model universes. We just | have | > | multiple Metacello repositories: | > | > | > | > - MetacelloRepository is the one that everybody can commit to | > | (testing universe) | > | > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo | 1.0 | > | > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo | 1.1 | > | > - etc. | > | | > | Yes this is what I was thinking. | > | In general the policy for a metacello config is to be in the | project | > | where it belongsto and **copied** to the MetacelloRepository. | > | | > | > A package always first gets into the testing universe and when | it is | > | known to work in a particular version it is copied into the | > | appropriate repository. The Gofer Project Loader would just need | to | > | know the repository for the current Pharo version. Like in Debian, | one | > | can add the testing universe to get unstable versions if needed. | > | > | > | > This setup would not need any code changes in Metacello and it | > | allows us to use access rights to assign people to manage the | process | > | and assert a certain level of quality. | > | | > | Yes! | > | | > | > | > | > Cheers, | > | > Adrian | > | > | > | > | > | > On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote: | > | > | > | >> El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió: | > | >>> ----- "Esteban Lorenzano" <estebanlm@gmail.com> wrote: | > | >>> | > | >>> | > - any idea about how we go to differentiate "stable" and | > | "unstable" | > | >>> | | > | >>> | > universes for each Pharo version? How does the user know | which | > | version | > | >>> | > is the one he needs for his version of Pharo? Sorry, this | is | > | not | > | >>> | > directly related to the Gofer Project Loader but I think | it is | > | the next | > | >>> | > important step towards a working package management | system! | > | >>> | | > | >>> | No clue... maybe we need to add to Metacello a new | "dependence | > | >>> | dimension", like "minimum version of distribution"... but | Dale | > | can be | > | >>> | much more helpful than me in this area. | > | >>> | > | >>> I imagine that code targetted for specific Pharo versions will | be | > | treated like we treat code targeted for different Smalltalk | dialects. | > | So you would write specs like the following: | > | >>> | > | >>> spec for: #common do: [...]. | > | >>> spec for: #squeakCommon do: [...]. | > | >>> spec for: #pharo do: [...]. | > | >>> spec for: #'pharo1.0' do: [...]. | > | >>> spec for: #'pharo1.1' do: [...]. | > | >>> | > | >>> or possibly like the following, if a finer version granularity | is | > | needed: | > | >>> | > | >>> spec for: #common do: [...]. | > | >>> spec for: #squeakCommon do: [...]. | > | >>> spec for: #pharo do: [...]. | > | >>> spec for: #'pharo1.0' do: [...]. | > | >>> spec for: #'pharo1.0-10508' do: [...]. | > | >>> spec for: #'pharo1.0-10515' do: [...]. | > | >>> spec for: #'pharo1.1' do: [...]. | > | >>> spec for: #'pharo1.1-11508' do: [...]. | > | >>> spec for: #'pharo1.1-11515' do: [...]. | > | >>> | > | >>> Dale | > | >>> | > | >> | > | >> umm, no please! | > | >> | > | >> There would be a lot of combinations after a while. | > | >> | > | >> Why about having a new spec universes message that accept a | list | > | of | > | >> symbols, each symbol representing a given "universe" of tested | > | packages. | > | >> This list will be the only thing to modify when grouping | different | > | >> versions of the same package in different repositories. | > | >> | > | >> For example, I start with ConfigurationOfMagma version 1.0r43. | Two | > | weeks | > | >> later I release ConfigurationOfMagma with support for loading | > | 1.0r44. | > | >> Both this versions have been tested on Pharo 1.0. So the both | are | > | >> marked | > | >> | > | >> spec universes: #(#pharo10). | > | >> | > | >> A week later Pharo 1.1 is released, and I test the | configuration on | > | this | > | >> new version of pharo. Both work ok. So I modify the line to: | > | >> | > | >> spec universes: #(#pharo10 #pharo11) | > | >> | > | >> and commit. | > | >> | > | >> The tools (GoferProjectLoader) then add functionality to scan | this | > | list | > | >> and presents the users only the appropriated ones based on the | > | image the | > | >> users is querying the repository. | > | >> | > | >> Of course this is very simplistic because as the debian model | > | shows, | > | >> requires a maintainer of each configuration and the user to | report | > | if a | > | >> given #pharo11 marked version actually doesn't work. If | something | > | don't | > | >> work, or a new version is given that works, or the tag #pharo11 | is | > | >> removed from that version effectively removing it from that | given | > | >> universe until bugs are fixed or worked around. | > | >> | > | >> What do you think? | > | >> | > | >> Cheers | > | >>> _______________________________________________ | > | >>> Pharo-project mailing list | > | >>> Pharo-project@lists.gforge.inria.fr | > | >>> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | >> | > | >> -- | > | >> Miguel Cobá | > | >> http://miguel.leugim.com.mx | > | >> | > | >> | > | >> _______________________________________________ | > | >> Pharo-project mailing list | > | >> Pharo-project@lists.gforge.inria.fr | > | >> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > Pharo-project@lists.gforge.inria.fr | > | > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | > | | > | _______________________________________________ | > | Pharo-project mailing list | > | Pharo-project@lists.gforge.inria.fr | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/3/18 Adrian Lienhard <adi@netstyle.ch>:

Here is yet another way how we could model universes. We just have multiple Metacello repositories:

- MetacelloRepository is the one that everybody can commit to (testing universe) - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 - etc.

A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed.

This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality.

And what if my project is intended to load in Squeak also? Or gemtone? Where should I put it? Does this approach imply that there should be created appropriate repositories? Doesn't this imply duplication of code between different configurations (which is avoided now using #common specifier) if the package can be loaded with only minor changes in all forks? And doesn't this imply removing all the code related to the fork specifier handling in Metacello? Just curious :) George

Thanks for the explanation, Dale! May be it's obvious and I'm asking stupid questions but then I don't understand how can I specify in my configuration the differences between the versions of the target platform? 2010/3/20 Dale Henrichs <dale.henrichs@gemstone.com>:

George,

The mcz files containing the Metacello configurations _are_ copied, but the configuration itself is not modified in the scheme.

The idea of using different repositories is to indicate which of the many different projects are _expected_ or _known_ to work in Pharo1.1 or Pharo1.0.

For GemStone, I have createed a GemSource MetacelloRepository and I have copied the metacello configurations that I know have been ported to GemStone. I've done this so that folks can know what is supported. I make sure that all of the tests run green and that all of the configs in the GemSource MetacelloRepository can be loaded.

It does not stop someone from loading a configuration into GemStone that isn't in the GemSource MetacelloRepository, but if you do and run into trouble, my answer will probably be that it hasn't been ported yet.

The same thing can apply to Squeak, but someone would have to step up to testing/approving metacello configurations that run with the various versions.

Without this extra step of approval/testing, it's difficult for someone that doesn't have their finger on the pulse of the latest and greatest happenings to know what to expect ...

Dale

Hi Esteban, I like to come back to your cool Project Loader... I have some suggestions and questions: - I propose to add a message named #help and output the info for each operations like you do on the website [1] - The result of evaluating list or search: is not very nice because it contains OrderedCollection (...) etc. I suggest to return a formatted string that looks nicer. - Wouldn't it be convenient to have a method Gofer>>loadPackagerLoader (or similar) in Gofer that would do [2]? We could ask Lukas to add it to Gofer. Now the important one point: When we create repositories MetacelloRepositoryPharo1.0 and MetacelloRepositoryPharo1.1 etc. it would be nice if the project loader was automatically initialized with the appropriate repository in each image depending on its version. This could be done by checking for "SystemVersion current" in the method GoferProjectLoader class>>createRepositories. What do you think? In addition I would add the command "unstable" (or similar) for adding the unstable/testing repository "MetacelloRepository". Cheers, Adrian [1] http://www.smallworks.com.ar/en/community/GoferProjectLoader [2] Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGoferProjectLoader'; load. ConfigurationOfGoferProjectLoader project lastVersion load. On Mar 18, 2010, at 08:30 , Adrian Lienhard wrote:

Here is yet another way how we could model universes. We just have multiple Metacello repositories:

- MetacelloRepository is the one that everybody can commit to (testing universe) - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 - etc.

A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed.

This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality.

Cheers, Adrian

On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote:

...

El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió:

...

----- "Esteban Lorenzano" <estebanlm@gmail.com> wrote:

| > - any idea about how we go to differentiate "stable" and "unstable" | | > universes for each Pharo version? How does the user know which version | > is the one he needs for his version of Pharo? Sorry, this is not | > directly related to the Gofer Project Loader but I think it is the next | > important step towards a working package management system! | | No clue... maybe we need to add to Metacello a new "dependence | dimension", like "minimum version of distribution"... but Dale can be | much more helpful than me in this area.

I imagine that code targetted for specific Pharo versions will be treated like we treat code targeted for different Smalltalk dialects. So you would write specs like the following:

spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...].

or possibly like the following, if a finer version granularity is needed:

spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.0-10508' do: [...]. spec for: #'pharo1.0-10515' do: [...]. spec for: #'pharo1.1' do: [...]. spec for: #'pharo1.1-11508' do: [...]. spec for: #'pharo1.1-11515' do: [...].

Dale

umm, no please!

There would be a lot of combinations after a while.

Why about having a new spec universes message that accept a list of symbols, each symbol representing a given "universe" of tested packages. This list will be the only thing to modify when grouping different versions of the same package in different repositories.

For example, I start with ConfigurationOfMagma version 1.0r43. Two weeks later I release ConfigurationOfMagma with support for loading 1.0r44. Both this versions have been tested on Pharo 1.0. So the both are marked

spec universes: #(#pharo10).

A week later Pharo 1.1 is released, and I test the configuration on this new version of pharo. Both work ok. So I modify the line to:

spec universes: #(#pharo10 #pharo11)

and commit.

The tools (GoferProjectLoader) then add functionality to scan this list and presents the users only the appropriated ones based on the image the users is querying the repository.

Of course this is very simplistic because as the debian model shows, requires a maintainer of each configuration and the user to report if a given #pharo11 marked version actually doesn't work. If something don't work, or a new version is given that works, or the tag #pharo11 is removed from that version effectively removing it from that given universe until bugs are fixed or worked around.

What do you think?

Cheers

...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project