>
>
> 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.
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' ];
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 ?
Dale?
�
Cheers
--