Metacello scripting: shared project lookup

If you look at the simplest scripting expression:


  Metacello new
    project: 'Seaside30';
    load.

It is clear that we have to support a lookup mechanism to resolve the 'Seaside30' to a particular version of the ConfigurationOfSeaside30 package.

GoferProjectLoader kept an ordered list of repositories that were searched in order to find the first occurrence of the ConfigurationOf package which was then used as the target ... The default list included 'http://www.squeaksource.com/MetacelloRepository' which was very nice.

I like the basic idea of having a repository search order for configurations and plan to maintain a repository lookup order for Metacello scripts. Instead of unconditionally including 'http://www.squeaksource.com/MetacelloRepository' in the list of repositories, we can include one or more platform-specific repositories where ConfigurationOf files are stored ... I think this is headed towards one of Stef's dreams to provide a controlled list of 'known to work' configurations for each Pharo version.

However, it has always bothered me that the Metacello loader and GoferProjectLoader didn't share the same lookup scheme.

In a project reference in a baseline you might see something like the following (extracted from a baseline version of Seaside30):

    spec
      project: 'Grease' with: [
        spec
          versionString: #'bleedingEdge';
          repository: 'http://www.squeaksource.com/Seaside30' ].

Note that the repository specified is not 'http://www.squeaksource.com/MetacelloRepository'.

If we assume that 'http://www.squeaksource.com/MetacelloRepository' is in the repository lookup list for a Metacello script, then the Grease configuration used by the following script:

  Metacello new
    project: 'Grease';
    load.

could very easily be different than the Grease configuration used by this script:

  Metacello new
    project: 'Seaside30';
    load.

In this case, ConfigurationOfGrease is resolved in terms of 'http://www.squeaksource.com/Seaside30' not 'http://www.squeaksource.com/MetacelloRepository' as in the first case, which can lead to different load experiences.

To make a long story short, I am proposing that when a load is initiated as a Metacello script, the Metacello scripting project lookup scheme will be shared by the Metacello loader.

I will provide details about specifying the lookup list in a separate post, but be assured that one will be able to control whether or not the shared lookup scheme is used or not ... as it turns out there are a number of interesting options, but I want to keep this post focussed on the idea of "to share or not to share"

The specific use case that I am thinking about is the case where there is a desire to provide users of Pharo 1.1 with a good experience in loading projects.

We can create a PharoMetacelloRepository1.1 and populate it with the versions of configurations that are known to work in Pharo1.1... but we must be able to guarantee that "all" configurations are looked up in PharoMetacelloRepository1.1, otherwise things can get out of control.

By sharing the Metacello scripting project lookup scheme we can start to make such guarantees....

There are additional use cases where sharing makes sense and I'll cover those in my post on the lookup options and control.

I think the option to share the lookup list is a good idea ...

I think consistency (within a user's environment) is extremely important.

As I mentioned earlier there are additional options that can be added to the lookup list to give developers much more control over the Metacello load environment than was possible before.

Dale



 

>
>
> I like the basic idea of having a repository search order for configurations and plan to maintain a repository lookup order for Metacello scripts. Instead of unconditionally including 'http://www.squeaksource.com/MetacelloRepository' in the list of repositories, we can include one or more platform-specific repositories where ConfigurationOf files are stored ... I think this is headed towards one of Stef's dreams to provide a controlled list of 'known to work' configurations for each Pharo version.

yes we are gutting closer and closer :)
>
> To make a long story short, I am proposing that when a load is initiated as a Metacello script, the Metacello scripting project lookup scheme will be shared by the Metacello loader.

sounds good.