Looks like GoferProjectLoader class>>createRepositories is the place to start...
Dale ----- "Adrian Lienhard" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 | > | >>> [email protected] | > | >>> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | >> | > | >> -- | > | >> Miguel Cobá | > | >> http://miguel.leugim.com.mx | > | >> | > | >> | > | >> _______________________________________________ | > | >> Pharo-project mailing list | > | >> [email protected] | > | >> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > [email protected] | > | > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | > | | > | _______________________________________________ | > | Pharo-project mailing list | > | [email protected] | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > _______________________________________________ | > Pharo-project mailing list | > [email protected] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | [email protected] | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
