[Metacello] Managing Pharo external packages with Metacello, please read!

[Mariano Martinez Peck]

Hi folks. We have been discussing a lot what to do with the Metacello configurations of all projects and MetacelloRepository.
We want several things:

- Have an specific catalog of the working and tested packages/projects for each Pharo release (1.0, 1.1, etc).
- Be able to have a hudson server running and testing such configurations.
- Unified way to load a project.

For such objectives, we propose the following scheme:

1) We create a squeaksource repository called Pharo10MetacelloRepository
2) All the Metacello configurations that are known and tested to work perfect in Pharo1.0, are copied to such repository. (this takes 2 minutes)
3) Now, we have the problem of WHICH version from the conf class should be the one that loads and works in Pharo 1.0. So, once you copied the configuration, then you have to implement a class side method "load" that loads the exact version that should work in Pharo1.0. This version may not be the last. And you already may have defined "load" to load the last version. In such case, you can just change it for the version in the Pharo10MetacelloRepository. Otherwise, we can use another message. Give us your opinion.

So the idea is that all developers/maintainers of Metacello configurations, do that and publish it. With this, if you want to know which projects work on Pharo 1.0 you just browser Pharo10MetacelloRepository, load the repository you want, and you know that just doing "ConfigurationOfXXX" load will do the job.

In addition to this, we are able to have a hudson server that every XX time, it scans the repository, and for each project it tries to load it and report if there is a problem. We can even make that "load" loads also the tests and make Hudson to run the tests. Or if you want we can use another message than load.

So...this is just an idea. But we need feedback and hear opinions. Because Pharo 1.1 will be soon and would be great to have this already working for Pharo 1.0.

Thanks

Mariano

[Mariano Martinez Peck]

On Sun, May 16, 2010 at 6:24 PM, Stéphane Ducasse <stephane...@inria.fr> wrote:

Mariano

I really want to have a separate folder for each version.
If this does not work then we will try something else. Why because I would like to have distribution.
Dale implemented a kind of freeze mechanism that copies all the dependent package of a project.
Then publishing to a given folder is a publication act and I like that it is explicit. It take less than a minute to copy
the given file to the 10 and 1.1 repository.

Now about you last point. Yes we need to freeze the version because loading the latest will not work and you want that people
just say load and not load: 14.2 here and load: 0.25 there. I'm correct?

Yes...imagine today you copy your Conf to Pharo10MetacelloConfiguration ... today the working version for Pharo 1.0 is  1.4.5.
Then...you continue to develop. Of course, using the same conf. Then you have version 1.5, 1.6, 1.6.2 , etc
Suppose that now we have Pharo1.1 and you do the same: you copy your new version of the conf to Pharo11MetacelloConfiguration.
How do people know WHICH version of the conf work for EACH pharo version ?   That's why I had the idea that every developer implement load to instead of loading the last version, to load the last version that WORKS for that Pharo version.

So probably, the conf you copy to Pharo10MetacelloRepository may be
load
        self version: '1.0.xx'  load

and in Parho11MetacelloRepository  it would be

load
       seld version: '1.6.xxx'

 this is just an example.

Having this, it also gives us an API: Everybody will know how to install it: just evaluate load.
And "us" can be extended to a bot -> continuous integration.

 

What is the alternative?

Stef

> _______________________________________________
> Pharo-project mailing list
> Pharo-...@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-...@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[stephane ducasse]

Yes.
It makes sense may be could even have
ConfigurationOfXXX freeze
which could do that automatically

Stef

[Miguel Enrique Cobá Martinez]

I was thinking about the "folders" to store copies of ConfigurationOfXXX
for a given release. I think that this will have problems, for example
for the simplest package that load fine in 3 consecutive release we will
have exactly 3 copies of the ConfigurationOfXXX package (not that the
disk space is a problem). On the other side, if a package has 19
versions for a given release (lets say RFB has 19 version methods in the
ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a
copy of it will be made. This copy will be full, having the 19 version
methods, or you just take the last version method. Also, what about the
pre/post do its, they will likely be similar or exactly equal between
releases of Pharo.
If you delete the methods, you also lost the history and the opportunity
that new users can learn or use the previous versions.

Some time ago I proposed the idea that Metacello should have tags to
mark that a version method has been tested in a given fork/release. As
the time pass, the tags in a method will grow to mark the version has
been tested on.
But for this to work, Metacello or the tools (I would prefer Metacello)
must honor this tags and before loading the code in a given image by
comparing what image is being installed on.

Lets put an example:

1. Initial creation of the configuration for package Package for Pharo
1.0 uploaded to MetacelloRepository:

ConfigurationOfPackage>>baseline01
"initial baseline"

ConfigurationOfPackage>>version01: spec
<version: '0.1'>

spec for: #common do: [
spec blessing: #release.
spec worksIn: 'Pharo1.0'
... ].

2. A new version for Pharo 1.0 (lets say a bug fix):

ConfigurationOfPackage>>version02: spec
<version: '0.2'>

spec for: #common do: [
spec blessing: #release.
spec worksIn: 'Pharo1.0'
... ].

3. A new Pharo release is made, no changes to the package are needed,
that is, it works correctly in Pharo1.0 and Pharo 1.1

ConfigurationOfPackage>>version03: spec
<version: '0.3'>

spec for: #common do: [
spec blessing: #release.
spec worksIn: #( 'Pharo1.0' 'Pharo1.1' )
... ].

At this point the ConfigurationOfPackage has four methods: baseline and
three versions. Also, before loading, Metacello checks the worksIn:
list against a standard release string in the image is working on. If
it match it install the package. That is, if I start with a Pharo1.1
image and load the configuration, the only possible candidate version
to install is the 0.3, because is the only one marked to work in Pharo1.1.

4. A port to Squeak 5 is made. This likely will need a new baseline
because will need squeak specific packages to be included
(compatibility packages) and also maybe a Pharo compatibility package
will be made. Anyway, a new baseline indicating new packages
relationships will be made:

ConfigurationOfPackage>>baseline02
"second baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version04: spec
<version: '0.4'>

spec for: #common do: [
spec blessing: #release.
spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' )
... ].
spec for: #squeak do: [
... ].
spec for: #pharo do: [
... ].

At this point the ConfigurationOfXXX is capable of install the last
version in Squeak and Pharo.

If I start on Squeak 4.0 then even if I load the
ConfigurationOfPackage, no package will be installed because nobody has tested this.

If I start on Squeak 5.0 only version 0.4 can be installed.

If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed

If I start on Pharo 1.3 no package will be installed

5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases
but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1

ConfigurationOfPackage>>baseline08
"second baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version09: spec
<version: '0.9'>

spec for: #common do: [
spec blessing: #release.
spec worksIn: #( 'Pharo1.3' 'Pharo1.4' )
... ].
spec for: #pharo do: [
... ].

6. Installing on Squeak 8 is again supported together with support for Squeak 7.0:

ConfigurationOfPackage>>baseline04
"third baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version10: spec
<version: '1.0'>

spec for: #common do: [
spec blessing: #release.
spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' )
... ].
spec for: #squeak do: [
... ].
spec for: #pharo do: [
... ].

So the tags come and go as the support for given forks and releases are
tested.
Different versions of the Package package can work in different forks
and in different releases of those forks.
It is always the job of the interested parties to add support (that is
version methods and baselines, or simply tags to the worksIn: list) for
a package in a given combination.

What do you think?

Cheers

--
Miguel Cobá
http://miguel.leugim.com.mx

[Miguel Enrique Cobá Martinez]

El lun, 17-05-2010 a las 09:49 +0200, Stéphane Ducasse escribió:
> I like the idea of tags.
> Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD
> with all the code included.

But look at Debian for example. They release a stable release, lets say
5.0 on January 15th. This is a iso image that includes a given set of
package versions, lets say

Package A version 1.1
Package B version 2.0
Package C version 2.1

then they continue working on testing and unstable versions of the
distro. Of course as the software is used all around the world, the
users report bugs and the developers push new versions with the fixes to
the debian repositories. The fixes can be bug fixes, security fixes and
new features. Only the security fixes and severe bug fixes are pushed to
the stable release (as well as to the testing and unstable branches of
course). This security fixes are part of the security updates for stable
installations of the distro.
But.. after a given number of security fixes and severe bug fixes are
collected, they release an update for the stable release, even
generating new .iso files. Suppose that they release an update in May
1st. They could call it Debian GNU/Linux stable 5.0.1.

The point is, even if I downloaded the stable release on January 15th,
it is different from the version you download on May 1st. They are both
called debian 5.0 stable and nobody expect that they are bitwise
identical.

But, when you install from the version from January and after updating
it from the update stream, I get the same packages that the person that
install its server from the version of May 1st.

I think the same can happen to Pharo. You release a given set of
versions (in the form of configurationOfXXX) but that doesn't means that
those are inmutable. They will be updated to match the packages that fix
bugs in a given external package.

Now for the generation of the release, you simply script it to use the
latest #released version of a configuration. That is the way that
Metacello works currently, installing the latest released version by
default.

Cheers


>
> Stef

> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-...@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-...@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project