El jue, 12-08-2010 a las 16:05 +0200, Mariano Martinez Peck escribió: > Hi Miguel. Sorry I was in a mini-holidays. > > thanks for the push :) > > Two weeks before (or similar) before this email, I've already created > the repositories: > > http://www.squeaksource.com/Pharo10Metacello
Yes, I saw them after my announce. Although I prefer prefix convention for repo an suffix for release, that way they list together in SqueakSource. MetaRepoForPharo10 MetaRepoForPharo11 etc > > > and > > http://www.squeaksource.com/Pharo11Metacello > > I didn't send any email because I was not sure about certain points. I > want to discuss them now: > > 1) Problem: know which project version must be used for a particular > pharo version. There are two solutions: > > a) When a developer commites ConfigurationOf to a particular repo, it > makes sure the #lastVersion answer the correct one. > b) When a developer commites ConfigurationOf to a particular repo, it > makes sure the #load will load the correct version. I think that for Pharo 1.0 and Pharo 1.1 there is little we can do as they are already outhere. The will continue referencing MetacelloRepository forever. And in that repo there are all the possible dependencies they need. So they need no change in the infrastructure. Now, if we forget about 1.0 and 1.1 and concentrate in 1.2, then we can make a big change. I propose: 1. Add to the image (maybe SystemVersion current metacelloRepository) a getter that returns the standardized string pointing to the correct metacello repository for the image: SystemVersion>>metacelloRepository ^ 'MetaRepoForPharo12' And then all the series of Pharo releases based on that PharoCore image will point to MetaRepoPharo12 (PharoCore 1.2, PharoCore 1.2.1, PharoCore 1.2.2, Pharo 1.2, Pharo 1.2.1, Pharo 1.2.4, etc. They are the same release family and supposedly "binary" compatible). For PharoCore 1.3, that string should be changed to SystemVersion>>metacelloRepository ^ 'MetaRepoForPharo13' and so on. That is the base image and derived images for Pharo. Now to the tools, Gofer, GoferProjectLoader and Metacello. Gofer ------ add a universe method (this name is overloaded so a better name is wanted, maybe metacelloRepository or pharoRepository) so that we can do: Gofer new universe; "or metacelloRepository or pharoRepository" project: 'ConfigurationOfMagma"; load. The universe (or whatever its name be) just uses SystemVersion current metacelloRepository to get everything from the correct repository. GoferProjectLoader ------------------ This could be improved to get every package (that is, a metacello configuration) from the correct repository by delegating to gofer new universe and avoiding to resolve itself the repository for the image. Also, if GoferProjectLoader is part of the core image, then maybe gofer shouldn't have the universe functionality, but GoferProjectLoader should have it, and only use gofer to fetch the monticello packages. This way I think is cleaner, because Gofer is only used as a medium to get things and knows nothing about universes and repositories depending on a given image release. Metacello ------------- This is the most difficult part. - Right now, Metacello hardcodes repository paths in the references to other projects. This isn't bad, but an alternative should be provided. That is, when referencing external projects like: project: 'Refactoring-Core' with: [ spec className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]; it should understand the alternative: project: 'Refactoring-Core' with: [ spec universe; "Or metacelloRepository or whatever" className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser' ]; So that a configuration could resolve all their references from the same pharo repository. This implies of course that the maintainer assures that all the referenced ConfigurationOfXXX are actually available in the repository referenced by SystemVersion current metacelloRepository. Of course nothing prevents for a configuration to reference a project outside the "universe" repository, but that is a decision of the maintainer. I think that this is the least disruptive way of integrating Metacello Repositories to next Pharo release. This preserves backwards compatibility and eases the way of installing packages in future releases. What do you think? Cheers -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
