[Pharo-project] [ANN] Pharo Metacello Universes
Hi all, I have created three new repositories on squeaksource: http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12 They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release. Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers. Most ConfigurationOfXXX packages in http://www.squeaksource.com/MetacelloRepository should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10. Then two things can follow: - If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11. - If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released) This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository. The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea. With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories. Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all. This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo. What this means to the end user: - For released version of Pharo They will have to use gofer this way: Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load. - For next releases of Pharo Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load. All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works. I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do: Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'. But wait to this change to be treated by Stephane or Lukas before attempt it. Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2. This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions. Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration) Comments and improvements welcome -- Miguel Cobá http://miguel.leugim.com.mx
Hi Miguel, Thanks! It's great to see progress on this front! Cheers, Adrian On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
Yes! Good push now I understand what you meant with Universe. Now two important comments for me: The problem One is that we are creating another vocabulary - Why not sticking with MetacelloRepositoryForPharo10? Like that we will not have to explain an Universe is a metacello repository..... Second point: what I would like is to have that all the dependent packages and configurations are copied into the metacelloRepository. I do not want to have dependency to any external servers. This way we will self-contained distribution. Do you handle that? Else this is great. Stef On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
Hi Miguel,
Thanks! It's great to see progress on this front!
Cheers, Adrian
On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
El mié, 04-08-2010 a las 11:49 +0200, Stéphane Ducasse escribió:
Yes! Good push now I understand what you meant with Universe.
Now two important comments for me:
The problem One is that we are creating another vocabulary - Why not sticking with MetacelloRepositoryForPharo10?
I have no problem with changing name. I think though that MetacelloRepositoryForPharo10 is very long but as the tools hide it maybe isn't a big problem either. Lets vote and if so, change it as soon as possible.
Like that we will not have to explain an Universe is a metacello repository.....
Second point: what I would like is to have that all the dependent packages and configurations are copied into the metacelloRepository. I do not want to have dependency to any external servers. This way we will self-contained distribution. Do you handle that?
I have read the discussions and yes that would be good but some things concern me: - Repository size (maybe this is not a problem but the squeak source downtime come to mind) - Load in the squeak source when sync is being done. - Who syncs the packages, Metacello when uploading¡ Some webmaster? A cron? - What about conflicting names in packages. - Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from squeaksource RFB repository and for any reason the packages are distinct (maybe a bug was found and republished in lukas repo with the same version number, but squeaksource version was copied before the fix was done) Maybe those problems never show. Anyway, the idea of having all available is good, but maybe not a task of Metacello, but as an independent effort. Metacello will just use the redundant repositories when installing a package. Cheers
Else this is great.
Stef
On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
Hi Miguel,
Thanks! It's great to see progress on this front!
Cheers, Adrian
On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
-- Miguel Cobá http://miguel.leugim.com.mx
I have read the discussions and yes that would be good but some things concern me: - Repository size (maybe this is not a problem but the squeak source downtime come to mind) memory disc is cheap
- Load in the squeak source when sync is being done. yes
- Who syncs the packages, Metacello when uploading¡ Some webmaster? A cron? the commiter press a button: "archive" and as a side effect all the packages are recursively pulled up and save :)
- What about conflicting names in packages. I would not bother right now.
- Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from squeaksource RFB repository and for any reason the packages are distinct (maybe a bug was found and republished in lukas repo with the same version number, but squeaksource version was copied before the fix was done)
the one loaded by the config should be the one saved.
Maybe those problems never show. Anyway, the idea of having all available is good, but maybe not a task of Metacello, but as an independent effort. Metacello will just use the redundant repositories when installing a package.
Cheers
Else this is great.
Stef
On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
Hi Miguel,
Thanks! It's great to see progress on this front!
Cheers, Adrian
On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
-- 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
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 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. a) is more complicated and require more time for the developer. It means you will have separate branches for each pharo version. The information is spread. with b) all the information is together in only one ConfOf in your own repo. Once it is needed, you just commit it to a particular Pharo repository and just change the #load I think b) is muuuuch easier. So...everybody knows how to install something "ConfigurationOf load". 2) Problem: projects may refer to other projects. And the referenced projects can be anywhere (for example, metacello repository). Example of ConfigurationOfOmniBrowser >> baseline11: project: 'Refactoring-Core' with: [ spec className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ]; So....ok., ConfigurationOfOmniBrowser will be in Pharo10Metacello (example). But...it will load the ConfigurationOfRefactoringBrowser from MonticelloRepository....WRONG!!! solution? a) change everything by hand....crap b) use repositoryOverride: b) can be used, but the problem (if I understood correclty) is that it replaces ALL repositories. So, you need to have EVERYTHING in that repo in order to work. 3) Problem: people will start to submit, may not maintain anymore, etc. I wouldn't make gloabl write such repositories. We should only give access to those that need it For me the most complicated problem is b). Ideas? Cheers Mariano On Wed, Aug 4, 2010 at 7:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
I have read the discussions and yes that would be good but some things concern me: - Repository size (maybe this is not a problem but the squeak source downtime come to mind) memory disc is cheap
- Load in the squeak source when sync is being done. yes
- Who syncs the packages, Metacello when uploading¡ Some webmaster? A cron? the commiter press a button: "archive" and as a side effect all the packages are recursively pulled up and save :)
- What about conflicting names in packages. I would not bother right now.
- Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from squeaksource RFB repository and for any reason the packages are distinct (maybe a bug was found and republished in lukas repo with the same version number, but squeaksource version was copied before the fix was done)
the one loaded by the config should be the one saved.
Maybe those problems never show. Anyway, the idea of having all available is good, but maybe not a task of Metacello, but as an independent effort. Metacello will just use the redundant repositories when installing a package.
Cheers
Else this is great.
Stef
On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
Hi Miguel,
Thanks! It's great to see progress on this front!
Cheers, Adrian
On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea
is
that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
-- 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
Before thinking how to store the configurations for the different versions of pharo(which I see as branches) we should think how to mantain different branches for each project with monticello in a comfortable way... Maybe the solution is to have one repository for each project, but I don't know if that make us lose history... 2010/8/12 Mariano Martinez Peck <marianopeck@gmail.com>
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
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.
a) is more complicated and require more time for the developer. It means you will have separate branches for each pharo version. The information is spread. with b) all the information is together in only one ConfOf in your own repo. Once it is needed, you just commit it to a particular Pharo repository and just change the #load I think b) is muuuuch easier. So...everybody knows how to install something "ConfigurationOf load".
2) Problem: projects may refer to other projects. And the referenced projects can be anywhere (for example, metacello repository). Example of ConfigurationOfOmniBrowser >> baseline11:
project: 'Refactoring-Core' with: [ spec className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ];
So....ok., ConfigurationOfOmniBrowser will be in Pharo10Metacello (example). But...it will load the ConfigurationOfRefactoringBrowser from MonticelloRepository....WRONG!!!
solution? a) change everything by hand....crap b) use repositoryOverride:
b) can be used, but the problem (if I understood correclty) is that it replaces ALL repositories. So, you need to have EVERYTHING in that repo in order to work.
3) Problem: people will start to submit, may not maintain anymore, etc. I wouldn't make gloabl write such repositories. We should only give access to those that need it
For me the most complicated problem is b). Ideas?
Cheers
Mariano
On Wed, Aug 4, 2010 at 7:29 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
I have read the discussions and yes that would be good but some things concern me: - Repository size (maybe this is not a problem but the squeak source downtime come to mind) memory disc is cheap
- Load in the squeak source when sync is being done. yes
- Who syncs the packages, Metacello when uploading¡ Some webmaster? A cron? the commiter press a button: "archive" and as a side effect all the packages are recursively pulled up and save :)
- What about conflicting names in packages. I would not bother right now.
- Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from squeaksource RFB repository and for any reason the packages are distinct (maybe a bug was found and republished in lukas repo with the same version number, but squeaksource version was copied before the fix was done)
the one loaded by the config should be the one saved.
Maybe those problems never show. Anyway, the idea of having all available is good, but maybe not a task of Metacello, but as an independent effort. Metacello will just use the redundant repositories when installing a package.
Cheers
Else this is great.
Stef
On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
Hi Miguel,
Thanks! It's great to see progress on this front!
Cheers, Adrian
On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea
is
that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
-- 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
2010/8/12 Guillermo Polito <guillermopolito@gmail.com>
Before thinking how to store the configurations for the different versions of pharo(which I see as branches) we should think how to mantain different branches for each project with monticello in a comfortable way...
I think this is confortable: you, developer, ALWAYS work with only ONE ConfiguratioOf that could be committed in the same repo where your code is. In that Conf you have all the hsitpry. Everything. Every X time, you think "mmmmm I will release 4.21 for Pharo 1.0". Perfect. You then commit such version of the Configuration into the repository Pharo10Metacello making that #load loads the 4.21 version. And that's all. You never merge between those packages. You only maintain one, that is commited in your own repo. Then, you just copy them (and change #load) to specific Pharo verisons. Here there is no need to merge and no problem. I am wrong ? Maybe the solution is to have one repository for each project, but I don't
know if that make us lose history...
2010/8/12 Mariano Martinez Peck <marianopeck@gmail.com>
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
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.
a) is more complicated and require more time for the developer. It means you will have separate branches for each pharo version. The information is spread. with b) all the information is together in only one ConfOf in your own repo. Once it is needed, you just commit it to a particular Pharo repository and just change the #load I think b) is muuuuch easier. So...everybody knows how to install something "ConfigurationOf load".
2) Problem: projects may refer to other projects. And the referenced projects can be anywhere (for example, metacello repository). Example of ConfigurationOfOmniBrowser >> baseline11:
project: 'Refactoring-Core' with: [ spec className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ];
So....ok., ConfigurationOfOmniBrowser will be in Pharo10Metacello (example). But...it will load the ConfigurationOfRefactoringBrowser from MonticelloRepository....WRONG!!!
solution? a) change everything by hand....crap b) use repositoryOverride:
b) can be used, but the problem (if I understood correclty) is that it replaces ALL repositories. So, you need to have EVERYTHING in that repo in order to work.
3) Problem: people will start to submit, may not maintain anymore, etc. I wouldn't make gloabl write such repositories. We should only give access to those that need it
For me the most complicated problem is b). Ideas?
Cheers
Mariano
On Wed, Aug 4, 2010 at 7:29 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
I have read the discussions and yes that would be good but some things concern me: - Repository size (maybe this is not a problem but the squeak source downtime come to mind) memory disc is cheap
- Load in the squeak source when sync is being done. yes
- Who syncs the packages, Metacello when uploading¡ Some webmaster? A cron? the commiter press a button: "archive" and as a side effect all the packages are recursively pulled up and save :)
- What about conflicting names in packages. I would not bother right now.
- Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from squeaksource RFB repository and for any reason the packages are distinct (maybe a bug was found and republished in lukas repo with the same version number, but squeaksource version was copied before the fix was done)
the one loaded by the config should be the one saved.
Maybe those problems never show. Anyway, the idea of having all available is good, but maybe not a task of Metacello, but as an independent effort. Metacello will just use the redundant repositories when installing a package.
Cheers
Else this is great.
Stef
On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote:
Hi Miguel,
Thanks! It's great to see progress on this front!
Cheers, Adrian
On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá MartÃnez wrote:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The
idea is
that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
-- 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
-- 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
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:
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
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.
ok
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' ];
But a spec is an object so we could have a visitor going over and doing the automatic rewrite for us.
Of course nothing prevents for a configuration to reference a project outside the "universe" repository, but that is a decision of the maintainer.
No this is a dogma. NO NO NO reference outside the repository. NOT A SINGLE ONE. NEVER. We want 100% self contained distribution. Stef
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' ];
But a spec is an object so we could have a visitor going over and doing the automatic rewrite for us.
maybe repositoryOverrides: does exactly that...I don't know
Of course nothing prevents for a configuration to reference a project outside the "universe" repository, but that is a decision of the maintainer.
No this is a dogma. NO NO NO reference outside the repository. NOT A SINGLE ONE. NEVER. We want 100% self contained distribution.
+99999
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El vie, 13-08-2010 a las 14:07 +0200, Stéphane Ducasse escribió:
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.
ok
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' ];
But a spec is an object so we could have a visitor going over and doing the automatic rewrite for us.
Of course nothing prevents for a configuration to reference a project outside the "universe" repository, but that is a decision of the maintainer.
No this is a dogma. NO NO NO reference outside the repository. NOT A SINGLE ONE. NEVER. We want 100% self contained distribution.
Stef
:) Ok.
_______________________________________________ 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
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 ? Dale?
Cheers
-- 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
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 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
-- Miguel Cobá http://miguel.leugim.com.mx
unfortunately we spent all the student money for this year. Stef On Aug 13, 2010, at 5:33 PM, Miguel Enrique Cobá MartÃnez wrote:
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.
Thinking aloud, and maybe saying something useless because the work may have started yet :P : Have you tought about something like - only one metacello config repository - ConfigOf understanding messages like #loadForPharoVersion: '1.0' or #loadInPharo10 or maybe just #load and request the pharo version to some object in the image? On Fri, Aug 13, 2010 at 5:26 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
unfortunately we spent all the student money for this year.
Stef
On Aug 13, 2010, at 5:33 PM, Miguel Enrique Cobá MartÃnez wrote:
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/15 Guillermo Polito <guillermopolito@gmail.com>
Thinking aloud, and maybe saying something useless because the work may have started yet :P :
Have you tought about something like
- only one metacello config repository - ConfigOf understanding messages like #loadForPharoVersion: '1.0' or #loadInPharo10 or maybe just #load and request the pharo version to some object in the image?
Because with this approach there are still missing features we want: 1) Easily browse the available confs for a particular pharo version....how you do this? ok...maybe you can ask if the clkass undrestands #loadInPharo10 but it is more complicadte...Having different repos, we can just use the normal Monticello browser 2) We want to be self contained. Not only ConfOf packages, but also all packages should be backuped. You take an snapshot of the Conf and ALL the packages it uses. WIth this you are sure that in 10 years they will be able to laod it again. No problem if the owner removes packages from te repo or similar Cheers Mariano
On Fri, Aug 13, 2010 at 5:26 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
unfortunately we spent all the student money for this year.
Stef
On Aug 13, 2010, at 5:33 PM, Miguel Enrique Cobá MartÃnez wrote:
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.
_______________________________________________ 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
this was more or less what I had in mind but with a limited knowledge of metacello. Stef
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
-- 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
Stef, Can we arrange to have a discussion about this issue at ESUG? There are a number of closely related things that need to be considered and I think that with email it is not easy ... Dale Stéphane Ducasse wrote:
this was more or less what I had in mind but with a limited knowledge of metacello.
Stef
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
-- 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
yes this will be much more efficient with a black board stef On Aug 17, 2010, at 12:25 AM, Dale Henrichs wrote:
Stef,
Can we arrange to have a discussion about this issue at ESUG? There are a number of closely related things that need to be considered and I think that with email it is not easy ...
Dale
Stéphane Ducasse wrote:
this was more or less what I had in mind but with a limited knowledge of metacello. Stef
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
-- 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
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.
a) is more complicated and require more time for the developer. It means you will have separate branches for each pharo version. The information is spread. with b) all the information is together in only one ConfOf in your own repo. Once it is needed, you just commit it to a particular Pharo repository and just change the #load I think b) is muuuuch easier. So...everybody knows how to install something "ConfigurationOf load".
I like b
2) Problem: projects may refer to other projects. And the referenced projects can be anywhere (for example, metacello repository). Example of ConfigurationOfOmniBrowser >> baseline11:
project: 'Refactoring-Core' with: [ spec className: 'ConfigurationOfRefactoringBrowser'; loads: #('Refactoring-Core' ); file: 'ConfigurationOfRefactoringBrowser'; repository: 'http://www.squeaksource.com/MetacelloRepository' ];
So....ok., ConfigurationOfOmniBrowser will be in Pharo10Metacello (example). But...it will load the ConfigurationOfRefactoringBrowser from MonticelloRepository....WRONG!!!
solution? a) change everything by hand....crap b) use repositoryOverride:
b) can be used, but the problem (if I understood correclty) is that it replaces ALL repositories. So, you need to have EVERYTHING in that repo in order to work.
yes this is the idea the process should fetch everything and copy it.
3) Problem: people will start to submit, may not maintain anymore, etc. I wouldn't make gloabl write such repositories. We should only give access to those that need it
Hi, Cool, I'll update Gofer Project Loader to understand this repositories... what we are going to do with MetacelloRepository? Cheers, Esteban On 2010-08-04 05:21:55 -0300, Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com> said:
Hi all,
I have created three new repositories on squeaksource:
http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12
They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release.
Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers.
Most ConfigurationOfXXX packages in
http://www.squeaksource.com/MetacelloRepository
should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10.
Then two things can follow:
- If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11.
- If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released)
This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository.
The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea.
With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories.
Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all.
This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo.
What this means to the end user:
- For released version of Pharo
They will have to use gofer this way:
Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load.
- For next releases of Pharo
Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load.
All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works.
I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do:
Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'.
But wait to this change to be treated by Stephane or Lukas before attempt it.
Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2.
This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions.
Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration)
Comments and improvements welcome
Hi, Cool, I'll update Gofer Project Loader to understand this repositories... what we are going to do with MetacelloRepository?
I would like to keep the name metacelloRepositories.
Cheers, Esteban
On 2010-08-04 05:21:55 -0300, Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com> said:
Hi all, I have created three new repositories on squeaksource: http://www.squeaksource.com/UniverseForPharo10 http://www.squeaksource.com/UniverseForPharo11 http://www.squeaksource.com/UniverseForPharo12 They are the repositories for the current versions of Pharo. The idea is that each new release add a new UniverseForXXX repository and populates it with the current UniverseForXXX packages of the stable release. Right now they are mostly empty, but should be populated by the community and the ConfigurationOfXXX maintainers. Most ConfigurationOfXXX packages in http://www.squeaksource.com/MetacelloRepository should be copied to UniverseForPharo10. Which versions? The last known version that is working correctly on Pharo 1.0. This will be the official universe for Pharo1.0. No ConfigurationOfXXX should be stored on UniverseForPharo10 if it is not working correctly on Pharo10. Then two things can follow: - If the package already has ConfigurationOfXXX package versions that work in Pharo 1.1, those versions should be copied to UniverseForPharo11. - If the ConfigurationOfXXX only works for Pharo1.0 and the maintainer want to create the configuration for Pharo 1.1, he/she must copy the last working configuration for the package from UniverseForPharo10 to UniverseForPharo11. There he/she can start modifying the package until it works correctly in Pharo1.1 (use the blessing: tags wisely to avoid marking a broken configuration as released) This will permit to populate the UniverseForPharo11 based on the last working package versions from UniverseForPharo10. From that point they will likely diverge because of maintenance releases to the packages in any UniverseForXXX repository. The same will must be done to migrate from UniverseForPharo11 to UniverseForPharo12. You get the idea. With time, MetacelloRepository should be deprecated in favor of this UniverseForXXX repositories. Anyone is free to copy a working version from a previous Universe to a new Universe. They have read/write permissions to all. This setup will avoid the problems we are having right now with the in-image changes that are rendering the ConfigurationOfXXX unusable in distinct releases of Pharo. What this means to the end user: - For released version of Pharo They will have to use gofer this way: Gofer new squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" project: 'ConfigurationOfMagma'; load. ConfigurationOfMagma project latestVersion load. - For next releases of Pharo Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" ConfigurationOfMagma project latestVersion load. All this depends on conventions to find the appropriate universe for each pharo release, and also in the support from tools (like gofer in this example or the GoferProjectLoader if it is part of the core image). The universe functionality of the tools right now rely on the SystemVersion current majorMinorVersion string for deciding which repository to connect to. This could be improved surely but for now it works. I'm loading a new version of Gofer to PharoInbox with this functionality added so if you want to load directly from the universes with gofer do: Gofer upgrade. Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'. But wait to this change to be treated by Stephane or Lukas before attempt it. Right now there is only Magma in the three repositories, but it shouldn't be hard for the maintainers of the other Configurations to help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2. This will benefit us as a community because the universes for the released pharo versions will be mostly untouched (only maintenance releases) and people will have the freedom to modify the configuration in the unstable (currently UniverseForPharo12) universe without affecting the users of the stable versions. Also, this will avoid to have a lot of conditionals inside the ConfigurationOfXXX classes, because a given class will target a specific Pharo release (the version on the newest universes could even delete the methods for the old universe, because will likely won't work in the new universe, deleting unnecessary and legacy code from the configuration) Comments and improvements welcome
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Adrian Lienhard -
Dale Henrichs -
Esteban Lorenzano -
Guillermo Polito -
Mariano Martinez Peck -
Miguel Enrique Cobá MartÃnez -
Stéphane Ducasse