Managing Pharo external packages with Metacello, please read!

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Mariano,



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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?
What is the alternative?

Stef



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> I think Andreas' recent post to squeak-dev is most cogent o this topic:

Eliot believe me we talk a lot of metacello since at least ESUG last year :)
We support and appreciate dale's effort (even when people bashed metacello a while ago).
So I think that we have a solution that looks ok for us.
We started to see how we can manage pharoCore to produce pharoMini using metacello
and what hamper us to remove more aggressively package is the speed of load monticello packages.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Stef
On May 16, 2010, at 6:35 PM, Mariano Martinez Peck wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Stef,

You obviously didn't read Andreas post. Please do it, it is really good
idea, which includes Metacello, it is simple and very similar to
Mariano's proposal. This means that a common solution for both Squeak
and Pharo is around a corner and that's what we all want!

Best regards
Janko

On 16. 05. 2010 18:26, Stéphane Ducasse wrote:

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes, it is similar to Andreas post. We were thinking about this since a lot of time but without making progress. Now, with the post of Andreas, we remembered about it. And I am happy both proposal are similar. Little differences:

- They want one only package for all confs. We want one package per configuration. Like we did in MetacelloRepository. I think it is easier to manage, less conflicts (imagine if everybody is commiting in the same package) and easier to browse.

- They didn't say how to solve the problems with multiple version. What will they do when they have squeak 5 ? use the same package ? another one ? other repo ?

- How do they know which version of the configuration works on the current version of squeak?  So...I browse ConfigurationOfFFI, how do I know that the version 1.1.4 is the one that works in Squeak 4.1   and that the 1.2 is the one that works in Squeak 4.2 ?  Of course, you can put such information inside the configuration, maybe in #description: or similar...but in all cases, you have to enter and browse the conf. We don't want that.

- We wanted to define a standard way to load the packages on such repository: just send the message load.

I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed.

What we want in summary is: is a repository of projects tested that works for a particular release of Pharo and that they all get installed in the same way. And that such installation can be executed any time in future.

Cheers

Mariano




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

another cool thing is that we are going to be able to distribute a Pharo release with the correct repository as default (already added in Monticello Browser)

So, in Pharo1.0 we add by default the repo Pharo10MetacelloRepository  
for Pharo1.1 we add Pharo11MetacelloRepository.

Then, when someone wants to install something, just need to browse the repository, select what he wants, load it and then just evaluage ConfigurationOfXXX load.


Cheers

mariano



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

well...
I read it before and the answer I sent to the remark of eliot is still valid.
Did you realize that we think about package since we started to work on 3.9, so having a system like
metacello was really what we wanted because packages without management of dependency
cannot scale.

Stef


On May 16, 2010, at 8:47 PM, Janko Mivšek wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

we will release 1.1 rc this week...
No need to get an email about andreas to know that you do not want to mix 1.0 and 1.1 configurations.

Stef


On May 16, 2010, at 9:17 PM, Mariano Martinez Peck wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

+ 1

especially on this one.
> I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed.





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I posted this on Squeak-dev @ http://forum.world.st/Community-Supported-Packages-td2217473.html#a2218970:

I eagerly read all the discussions and offer my humble contribution (posting to Pharo too, because I think the benefit is cross-platform):

I'm overjoyed that we are digging in and making packages easily loadable (or clear that they are not).  I don't know what I'll do with all the hours I currently spend fishing for working versions ;-)

Overall the goals seem to be (put best in a post from Mariano Peck):
* have a specific catalog of working and tested projects for each platform (Pharo 1.0, Pharo 1.1, Squeak 4.0, Squeak 4.1...)
* Be able to have a hudson server running and testing such configurations.
* Unified way to load a project.
* (I added this one) have the least amount of effort for the developer

The Pharo and Squeak versions both sound intriguing.  I suggest one addition that would magnify all of the above, and eliminate the accidental complexity that versioning is adding to the mix:

***Extend Metacello specs to account for platform version (e.g. Pharo 1.0 vs. 1.1)***

In effect, since we are distilling the platforms down to the pure good stuff - each version is a whole different platform; from a developer's perspective, it's the same process porting to different forks and porting to new versions of the same fork - either way, incompatible interfaces.

A hypothetical developer perspective:
        - Porting from Squeak to Pharo: I'm a developer with a project that works on Squeak 4.0.  Now, I decide to port it to Pharo 1.0.  So I crank up a new image and... wait, how do I load it?  I don't have a ConfigOf.  So I either alter the Config #squeak to #squeakCommon, or load manually.  Now, it doesn't load because there are classes that don't exist in Pharo, so one by one, I move the platform-specific code into Platform.squeak and Platform.pharo.
        - Pharo 1.0 to Pharo 1.1: Now, Pharo 1.1 is released, with even fewer classes - tight core, yay!  So I go through the same process, but now I have *three platforms* - Pharo 1.0, 1.1, and Squeak 4.0.

User perspective: simple - I want to have *one* place to go where I know that all the packages there will work in my image, and cut out all the junk.  And, if I'm feeling adventurous, I'd like *one* place to see what else is out there, but very clear that it's not up to community standards - for inspiration, to port to my platform, or to steal code :)

Once you have Metacello handling the versions
* the developers go from fork*version configs to one config
* the version problem is handled
* all other features of the current plans are preserved

This is what I envision at the intersection of what's been proposed and Metacello versioning:
* Configs are either:
        - in one central location; it won't matter because we went from projects*forks*versions Configs to just 1*projects.
        - or, kept with the projects they reference e.g. pick squeaksource.com, and every project repository keeps its own ConfigurationOf (might diminish the community involvement if read-only repos)
        >Andreas (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473):
        >Good things about it are that
        >it's community maintained. Everyone can update everyone else's
        >contributions and although that's not generally done, it offers a
        >community approach to making sure things work.
* Each platform (fork + version combo) (via hudson server?  I don't know much about them) tries to load each Config from the central repository.  If it meets the community standards (no conflicts, tests, etc.), either the Config is copied to that platform/fork's list of compatible Configs, or a reference is added.
* If it doesn't load, another list could be kept with the result of the attempt to load, so anyone who wants to use or port it has a heads up on the status.

So:
* we don't need a separate Config for fork*version platforms.   Right now, it seems the implementation and behavior are collapsed - we don't care where the actual Configs are (at least in the Pharo plan), as long as we know which ones work.  Which resolves Andreas's concern with a single repository:
        > Andreas (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473):
        > Also, I don't think that a single repository is a feasible option in the long
        > term - it seems to me that supporting the cross-product of image and
        > package versions is going to be problematic before too long. And of
        > course browsing repositories with several dozen of packages to find what
        > you need isn't exactly fun either.
and eliminated manual fiddling with the Config file:
        > Pharo proposal @ http://groups.google.com/group/metacello/browse_thread/thread/42c088d58acfb363
        > [developers will copy configs that work in Pharo x.y to] PharoxyMetacelloRepository, then add class>>load for Pharo 1.0 version.
* there is still one place to install for a user's platform
* you really do get "a standard way to load the packages on such repository: just send the message load" because the spec already knows whether it will work on that platform
* you still get a Pharo [and Squeak] release with the correct repository as default (already added in Monticello Browser) - this is your list you copied over

Thanks.
Sean

El dom, 16-05-2010 a las 09:14 -0700, Eliot Miranda escribió:
> Hi Mariano,

>
>
> I think Andreas' recent post to squeak-dev is most cogent o this
> topic:
>  

I don't see why.

Lets see, Andreas said:


"While looking into Metacello I also spent some time at the Pharo
Metacello repository on Squeaksource. There are many interesting things
to be said about it, both good and bad. Good things about it are that
it's community maintained. Everyone can update everyone else's
contributions and although that's not generally done, it offers a
community approach to making sure things work. Something that for
example both Universes and Squeakmap lack completely. What's problematic
about the repository on the other hand is that for one thing one needs
to unconditionally trust the code even before one has even decided to
install it (this by far my biggest complaint about Metacello)."

I don't buy this, how is this different than loading a package
(Seaside, RFB, whatever) from SqueakSource in my image. Unless I browse
the full code in SqueakSource (slow as hell), I don't have any
guarantees that the code doesn't does a true become: false in some
initialization method somewhere. The same applies to the
ConfigurationOfXXX packages. The advantage of loading it to your image
is that at least you can use a real environment to analyze the code. If
you are using the loader to update your critical mission deployment,
well, given the current security foundations of Smalltalk, you're
betting to the wrong horse. If you want more security is a matter of
signing the package in Squeaksource somehow and checking the signature
on loading in the image (like every reasonable linux distro does
currently on installing packages), or using some kind of sandbox for
loading untrused code. But that is completely other issue and has
nothing to do with the Metacello way of work. In fact, Metacello it
could be enhanced to check some kind of signature before loading and
then the trust problem will be real targeted.


 "Also, I
don't think that a single repository is a feasible option in the long
term - it seems to me that supporting the cross-product of image and
package versions is going to be problematic before too long. And of
course browsing repositories with several dozen of packages to find what
you need isn't exactly fun either."

Of course, nobody denies that, and in fact is an issue that has been
discussed several times before in this list. Check the Loader code that
is being worked on. It searches, installs, and is easier to write than
directly use ConfigurationOfXXX messages.

"However, the problems can be turned on their head, and that's actually
pretty insightful. Here's the basic idea: What if, instead of having a
single repository for all image versions with separate packages for each
config, we would instead have a single package simply called
Configurations in the trunk?

That Configurations package would contain all the "supported"
configurations for Squeak (I'll get to that in a minute). The package
would be community-maintained, just like any other package in trunk
development process. This addresses the trust issues with Metacello,
since the package has the same level of trust that all the other
packages in a Squeak release have; it has been developed using the same
principles."

Won't work, because not everybody works on Squeak, in fact, most
ConfigurationOfXXX have been created and tested first on Pharo. The
idea Andreas propose is to have a Squeak configuration and Pharo a
Pharo configuration, that very likely will be a hell of copy & paste of
methods. The good thing of having separate ConfigurationOfXXX packages
in a neutral repository (MetacelloRepository) is that everybody can add
methods (one for each version and for each one of Squeak and Pharo if
necessary) to a only one Configuration. What you propose is to forget
that there are users of a package in both camps and that your solution
propose that the maintainer create two or  more configuration packages
in distinct repositories (one for Squeak in trunk repo and one for
Pharo in MetacelloRepository). This is not funny. Also, this just add
other package to the base image, a package that will change a lot
between different Squeak releases. Squeak 5 will have a package with 10
configurations, Squeak 6 will have a package with 45 configurations.
The idea of core package or base package is that the package is not
changing a lot between releases. Current ConfigurationOfXXX only needs
Gofer or Installer in the base image. Maybe a future Pharo release will
have Gofer and Loader in the base image but Loader doesn't grow
unrestricted between Pharo releases. The MetacelloRepository will do.



"What that gives us is a mechanism by which we suddenly can include
Omnibrowser, Seaside, Magma, FFI and anything else people can come up
with in Squeak without having to preload it in the shipping image."

This is funny, I haven't realised that to this day it is imposible to
have a Pharo Core image without packages installed by default. Good to
know that this will be possible soon with this new Configurations package.


"What
it also means is that we can start removing packages from the image,
replacing them with the proper configurations for how to load them back.
What it means is that somebody with a new application (be that
Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask
for the configuration to be part of the next Squeak release, thereby
contributing *directly* to that Squeak version."

And this is really what I don't understand of the Squeak fellows, why,
why should someone *ask* someone (people or board or institution) for
permission to add a package to a released Squeak. Why? Why should I
wait for the next release for my package to be *accepted*? This is
non-sense. The current state of affairs permit me, even now that Pharo
1.0 has been released, to release my own package *aimed* on Pharo1.0 by
just testing that works and publishing my ConfigurationOfXXX in the
MetacelloRepository. The proposed solution is just plain wrong and
completely "Squeakish" (lets have everything in the image)



"Most importantly, however, is that we as the community can decide what
we feel we want to support and what not. "

What you base your judgements on to conclude this. The community decide
what ConfigurationOfXXX is created, tested and maintained or supported.





"To do that, I'm proposing to create a status of "Community Supported
Package" in Squeak. What is that? A community supported package is a
piece of software where we feel this is an important/interesting/novel
package that should ship with this Squeak version. A community supported
package can be loaded in a 'one-click' process directly from within the
image. A community supported package is a package where we provide
assurance that the package has been tested for this release."

How is this different from the current #released, #stable, #development
tags you can use in Metacello to mark the status level of a given
package in a given released Pharo or Squeak version?

"However, that status does not come for free. In return for achieving
this status, the software needs follow the rules for community supported
packages, which (at least) should include the following:

* No conflicts. Neither class names nor -override categories. The
rationale is that all community supported packages can be loaded
together without creating conflicts."

This is an artificial restriction. Debian and derived ones and Red Hat
and derived ones distros permit to install conflicting packages from
the same universe without problems. You see, is the decision of the
user and not the maintainer or distro packager what to install. For
example you can't install (well you can, but you shouln't most times)
Sendmail at the same time that Exim or Postfix. They are conflicting
packages and the system only warns you about the conflicts. But the
system permits you install them if you want. The same applies to the
overrides. If I want to install two packages that have overrides over
the same methods that is my problem. The system should only warn me and
let me do what I want.

"* Tests mandatory. A community supported package MUST have tests. The
rationale is that since we provide the guarantee that the package has
been tested, we need to ensure that testing can be automated to the
maximum extent possible. It doesn't mean 100% coverage but *some*
meaningful set of tests need to be provided or else we can't say if we
broke it in the latest update."

This is good no matter the package system on hand. But this is also an
artificial restriction. A package can work (and for a lot of people can
be useful) even if no single test is provided. Would you denied them the posibility of install the package in your image.

There may be some other guidelines that we may want to establish but I'm
trying to keep things simple and only the above two are truly crucial -
what they allow is to ensure that during ongoing trunk development we
will always be able to load all supported packages, run the tests and
see if we broke something horribly.

So the goal of the process is that if we do this right, we should be
able to tell how good (or how bad) a shape we're in regarding the
supported packages when we get to ship date. We should be able to
encourage people who write libraries or apps with, for, and in Squeak,
to contribute directly to the next release by providing a configuration,
their code, and the tests so that we can keep things running. In return,
we'll help with porting, provide backwards compatibility as required etc.

Code that we want to move out of the default image would be moved into a
configuration so people can load it if desired, and it remains a part of
Squeak instead of rotting away. Since the Configuration package is small
and has no dependencies, there's no problem to include that in
core/basic images and allow people to tailor custom images from there.

Concretely, I'm seeing the following steps as necessary:

1. Establish the status and the rules for "Community Supported Packages".

2. Create the "Configurations" package and start populating it with some
examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like.

3. Encourage people to bring their packages up to 'community standards'
and include them in the Configurations.

 From here, there are a few more things that we should do before we can
ship the next Squeak version:

4. Provide a better installer than these awful doIts for Metacallo.

5. Establish a test server to automatically verify the community
standards for supported packages (i.e., load packages randomly, ensure
no conflicts, run tests, report results).

At this point, there is another clearly defined way to contribute to
Squeak even if you're not a core developer: Develop your software,
provide a configuration, ensure your software adheres to the community
standards. That's it. You've just made the next Squeak release a little
better :-)

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sent before finish it, sorry

El dom, 16-05-2010 a las 09:14 -0700, Eliot Miranda escribió:
> Hi Mariano,

>
>
> I think Andreas' recent post to squeak-dev is most cogent o this
> topic:
>  

I don't see why.

Lets see, Andreas said:


"While looking into Metacello I also spent some time at the Pharo
Metacello repository on Squeaksource. There are many interesting things
to be said about it, both good and bad. Good things about it are that
it's community maintained. Everyone can update everyone else's
contributions and although that's not generally done, it offers a
community approach to making sure things work. Something that for
example both Universes and Squeakmap lack completely. What's problematic
about the repository on the other hand is that for one thing one needs
to unconditionally trust the code even before one has even decided to
install it (this by far my biggest complaint about Metacello)."

I don't buy this, how is this different than loading a package
(Seaside, RFB, whatever) from SqueakSource in my image. Unless I browse
the full code in SqueakSource (slow as hell), I don't have any
guarantees that the code doesn't does a true become: false in some
initialization method somewhere. The same applies to the
ConfigurationOfXXX packages. The advantage of loading it to your image
is that at least you can use a real environment to analyze the code. If
you are using the loader to update your critical mission deployment,
well, given the current security foundations of Smalltalk, you're
betting to the wrong horse. If you want more security is a matter of
signing the package in Squeaksource somehow and checking the signature
on loading in the image (like every reasonable linux distro does
currently on installing packages), or using some kind of sandbox for
loading untrused code. But that is completely other issue and has
nothing to do with the Metacello way of work. In fact, Metacello it
could be enhanced to check some kind of signature before loading and
then the trust problem will be real targeted.


 "Also, I
don't think that a single repository is a feasible option in the long
term - it seems to me that supporting the cross-product of image and
package versions is going to be problematic before too long. And of
course browsing repositories with several dozen of packages to find what
you need isn't exactly fun either."

Of course, nobody denies that, and in fact is an issue that has been
discussed several times before in this list. Check the Loader code that
is being worked on. It searches, installs, and is easier to write than
directly use ConfigurationOfXXX messages.

"However, the problems can be turned on their head, and that's actually
pretty insightful. Here's the basic idea: What if, instead of having a
single repository for all image versions with separate packages for each
config, we would instead have a single package simply called
Configurations in the trunk?

That Configurations package would contain all the "supported"
configurations for Squeak (I'll get to that in a minute). The package
would be community-maintained, just like any other package in trunk
development process. This addresses the trust issues with Metacello,
since the package has the same level of trust that all the other
packages in a Squeak release have; it has been developed using the same
principles."

Won't work, because not everybody works on Squeak, in fact, most
ConfigurationOfXXX have been created and tested first on Pharo. The
idea Andreas propose is to have a Squeak configuration and Pharo a
Pharo configuration, that very likely will be a hell of copy & paste of
methods. The good thing of having separate ConfigurationOfXXX packages
in a neutral repository (MetacelloRepository) is that everybody can add
methods (one for each version and for each one of Squeak and Pharo if
necessary) to a only one Configuration. What you propose is to forget
that there are users of a package in both camps and that your solution
propose that the maintainer create two or  more configuration packages
in distinct repositories (one for Squeak in trunk repo and one for
Pharo in MetacelloRepository). This is not funny. Also, this just add
other package to the base image, a package that will change a lot
between different Squeak releases. Squeak 5 will have a package with 10
configurations, Squeak 6 will have a package with 45 configurations.
The idea of core package or base package is that the package is not
changing a lot between releases. Current ConfigurationOfXXX only needs
Gofer or Installer in the base image. Maybe a future Pharo release will
have Gofer and Loader in the base image but Loader doesn't grow
unrestricted between Pharo releases. The MetacelloRepository will do.



"What that gives us is a mechanism by which we suddenly can include
Omnibrowser, Seaside, Magma, FFI and anything else people can come up
with in Squeak without having to preload it in the shipping image."

This is funny, I haven't realised that to this day it is imposible to
have a Pharo Core image without packages installed by default. Good to
know that this will be possible soon with this new Configurations package.


"What
it also means is that we can start removing packages from the image,
replacing them with the proper configurations for how to load them back.
What it means is that somebody with a new application (be that
Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask
for the configuration to be part of the next Squeak release, thereby
contributing *directly* to that Squeak version."

And this is really what I don't understand of the Squeak fellows, why,
why should someone *ask* someone (people or board or institution) for
permission to add a package to a released Squeak. Why? Why should I
wait for the next release for my package to be *accepted*? This is
non-sense. The current state of affairs permit me, even now that Pharo
1.0 has been released, to release my own package *aimed* on Pharo1.0 by
just testing that works and publishing my ConfigurationOfXXX in the
MetacelloRepository. The proposed solution is just plain wrong and
completely "Squeakish" (lets have everything in the image)



"Most importantly, however, is that we as the community can decide what
we feel we want to support and what not. "

What you base your judgements on to conclude this. The community decide
what ConfigurationOfXXX is created, tested and maintained or supported.





"To do that, I'm proposing to create a status of "Community Supported
Package" in Squeak. What is that? A community supported package is a
piece of software where we feel this is an important/interesting/novel
package that should ship with this Squeak version. A community supported
package can be loaded in a 'one-click' process directly from within the
image. A community supported package is a package where we provide
assurance that the package has been tested for this release."

How is this different from the current #released, #stable, #development
tags you can use in Metacello to mark the status level of a given
package in a given released Pharo or Squeak version?

"However, that status does not come for free. In return for achieving
this status, the software needs follow the rules for community supported
packages, which (at least) should include the following:

* No conflicts. Neither class names nor -override categories. The
rationale is that all community supported packages can be loaded
together without creating conflicts."

This is an artificial restriction. Debian and derived ones and Red Hat
and derived ones distros permit to install conflicting packages from
the same universe without problems. You see, is the decision of the
user and not the maintainer or distro packager what to install. For
example you can't install (well you can, but you shouln't most times)
Sendmail at the same time that Exim or Postfix. They are conflicting
packages and the system only warns you about the conflicts. But the
system permits you install them if you want. The same applies to the
overrides. If I want to install two packages that have overrides over
the same methods that is my problem. The system should only warn me and
let me do what I want.

"* Tests mandatory. A community supported package MUST have tests. The
rationale is that since we provide the guarantee that the package has
been tested, we need to ensure that testing can be automated to the
maximum extent possible. It doesn't mean 100% coverage but *some*
meaningful set of tests need to be provided or else we can't say if we
broke it in the latest update."

This is good no matter the package system on hand. But this is also an
artificial restriction. A package can work (and for a lot of people can
be useful) even if no single test is provided. Would you denied them
the posibility of install the package in your image. This only will
push users away from your image



"4. Provide a better installer than these awful doIts for Metacallo."

This is the job of the tools, as Dale has said from the beginning. And
there are tools to simplify the install of package both in a workspace
doit or with GUI

"5. Establish a test server to automatically verify the community
standards for supported packages (i.e., load packages randomly, ensure
no conflicts, run tests, report results)."

This is something also being worked on since a while. A Hudson server has been proposed for this.

"At this point, there is another clearly defined way to contribute to
Squeak even if you're not a core developer: Develop your software,
provide a configuration, ensure your software adheres to the community
standards."

But this already exists, or we live in different worlds?

So, what is really new or advantageous in this proposal? I really don't see it.

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



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El dom, 16-05-2010 a las 17:28 +0200, Mariano Martinez Peck escribió:
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Elliot believe me we **really** discussed that over more than a year with dale and a couple of others.
We pushed metacello contrary to other people that said it was crap and bloated.
So may be we are a bit slow and not that smart but we want to give a try to the setup we have in mind.
Now we also want to have a list of packages which constitutes pharo-core that will be manage as a pharo-core
configuration.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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.

Stef



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project