El vie, 13-08-2010 a las 15:53 +0200, Mariano Martinez Peck escribió: > > > > > > > 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. > > No...I think it is possible. It doesn't care they are out there. > Continue reaeding my answer. > > > 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: > > I wouldn't forget about 1.0 and 1.1 > > > 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. > > > All you mention here has sense to LOAD projects. And I agree this > changes could be only for Pharo 1.2 (like the change in > SystemVersion). > But someone should be able to do everything by code. For example, in > Pharo 1.0 I could do: > > Gofer new > repository: 'pharoRepository10" > project: 'ConfigurationOfMagma"; > load. > > But I think this is a further step. We need to FIRST think how to > WRITE the configuration. And how to load it with Metacello. I don't > care Gofer neither Loader for the first step. > > 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. > > > But we need to change that...in addition, there are confs that also > work in squeak...soo.. > > 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? > > I think that we should do is a piece of code that does the following: > > - Take a ConfiguraitonOfXXX and do a "publish in Pharo Repository" > - This can propmt which Pharo version, or directly which > PharoRepository > - Then it will ask which VERSION should be loaded in the already > selected Pharo version > - It should be asked WHICH group (optional) > > Once this is done, the code has to do the following: > > - Iterates all the project and packages referenced and COPY ALL OF > THEM into the same repository. Or maybe we can have another repo. > This will copy all the .mzc of the project and its dependencies. With > this you will make sure that you have EVERYTHING you need to load it. > > - take that ConfigurationOfXXX and automatically compile a class side > #load that based in your answers, does the correct job. > In addition, this method should do a repositoryOverride: with the > selected repository. > Example: > > load > | version | > version := self project version: selectedVersion. > version repositoryOverrides: selectedPharoRepository. > version load: selectedGroup. > > Maybe it can implement a particular load: that recieves the common > parameter >
> > > Then, if you are in Pharo 1.0 the only thing you have to do is to > explore the repository PharoRepository10 and browse the confs....you > select the one you want and load it (with Gofer or Monticello > Browser). Once that is done, you just evaluate: > > ConfiguarationOfXXX load. > > and that's all. > > What do you think ? I like the idea, but it requires a lot of effort in building the tool, that does that. Maybe INRIA could sponsor some student hours just to build this tool so that is ready for the 1.2 release. > Dale? > > > > 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 > > _______________________________________________ > 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
