Metacello scripting observation...

With the direction that I am currently headed, if one wanted to load multiple projects in a Metacello script one would write the following:

  Metacello new
    project: 'Seaside30';
    load;
 
    project: 'Sample';
    filetree: '/foos1/users/dhenrich/smalltalk/sample/';
    load;

    project: 'Sample';
    filetree: '/foos1/users/dhenrich/smalltalk/metacello/';
    load.

which is different than the current Gofer scheme, which queues up the things to be loaded like the following (a single load statement):


  Metacello new
    project: 'Seaside30';
 
    project: 'Sample';
    filetree: '/foos1/users/dhenrich/smalltalk/sample/';

    project: 'Sample';
    filetree: '/foos1/users/dhenrich/smalltalk/metacello/';
    load.

opinions?

Dale

Dale Henrichs wrote:

While filetree: looks like a local repository, I assume you'll have the
syntax when using a remote repository.  Considering some failure
use-cases for this I think the second is better.  Overall the assumption
is that a Metacello script "should" take the system from one consistent
state to another.

1. A metacello script takes packages from several remote repositories.  
The last one is off-line.  The first example might bring the system into
an inconsistent state by successfully loading half the packages.  I
think it better if all requires mcz packages are successfully downloaded
to the local package-cache, and their checksums validated before the
first begins to be loaded.

2. (Assuming I understand this correctly) There maybe a clash of mcz
versions required for the whole script.  In the first example a later
project may load a different version mcz than an earlier project in the
list.  The second example should allow for Metacello to know the total
of mcz's to be loaded by the script and alert if there are any clashes -
before the first mcz is loaded - and then provide a mechanism to choose
one mcz over another.

This also leads to another overall feature which would be to #validate
currently loaded mczs against a particular Metacello package version.  I
think you may have mentioned this feature elsewhere.


I think the above consistency checking might be the advantage of a
separate Metacello supervising process over just using Gofer loads (
which without being too familiar with it I assume would not provide
these features)

cheers, -ben

Ben,

Thanks for the feedback ... further responses embedded below ...

Dale

----- Original Message -----
| From: "Ben Coman" <[hidden email]>
| To: [hidden email]
| Sent: Friday, February 10, 2012 9:55:00 PM
| Subject: Re: [Metacello] Metacello scripting observation...
|
| Dale Henrichs wrote:
| > With the direction that I am currently headed, if one wanted to
| > load multiple projects in a Metacello script one would write the
| > following:
| >
| >   Metacello new
| >     project: 'Seaside30';
| >     load;
| >  
| >     project: 'Sample';
| >     filetree: '/foos1/users/dhenrich/smalltalk/sample/';
| >     load;
| >
| >     project: 'Sample';
| >     filetree: '/foos1/users/dhenrich/smalltalk/metacello/';
| >     load.
| >
| > which is different than the current Gofer scheme, which queues up
| > the things to be loaded like the following (a single load
| > statement):
| >
| >
| >   Metacello new
| >     project: 'Seaside30';
| >  
| >     project: 'Sample';
| >     filetree: '/foos1/users/dhenrich/smalltalk/sample/';
| >
| >     project: 'Sample';
| >     filetree: '/foos1/users/dhenrich/smalltalk/metacello/';
| >     load.
| >
| > opinions?
| >
| > Dale
| >
| >  
|
|
| While filetree: looks like a local repository, I assume you'll have
| the
| syntax when using a remote repository.  

The #filetree: is but one example of a repository specification ... there are many, including remote forms ...


| Considering some failure
| use-cases for this I think the second is better.  Overall the
| assumption
| is that a Metacello script "should" take the system from one
| consistent
| state to another.

Regarding error handling, there will be both interactive and batch modes for the scripts. In interactive mode, errors will be intercepted and analyzed and the user will be given choices of action.

In batch mode, no internal error handling will be done and it will be up to the calling code to do error handling if any ...
 
|
| 1. A metacello script takes packages from several remote
| repositories.
| The last one is off-line.  The first example might bring the system
| into
| an inconsistent state by successfully loading half the packages.  I
| think it better if all requires mcz packages are successfully
| downloaded
| to the local package-cache, and their checksums validated before the
| first begins to be loaded.

In general, when a configuration is loaded, Metacello fetches ALL of the necessary projects and packages and then does a pass loading all of the projects and packages ... My expectation (at the moment) is that even in the case where multiple projects are specified in a Metacello script, that each project will go through a fetch/load cycle individually, this could be changed in the future, I suppose ...


|
| 2. (Assuming I understand this correctly) There maybe a clash of mcz
| versions required for the whole script.  In the first example a later
| project may load a different version mcz than an earlier project in
| the
| list.  The second example should allow for Metacello to know the
| total
| of mcz's to be loaded by the script and alert if there are any
| clashes -
| before the first mcz is loaded - and then provide a mechanism to
| choose
| one mcz over another.

Version clash is a real possibility and in general there are no right answers because sometimes you just "can't have your cake and eat it too"...Recognizing these types of clashes is currently the responsibility of the developer.

|
| This also leads to another overall feature which would be to
| #validate
| currently loaded mczs against a particular Metacello package version.
|  I
| think you may have mentioned this feature elsewhere.

The #validate function checks for internal consistencies in configurations ... at the moment it does not reason about version consistencies ... There is enough information to provide the raw material for making these decisions, but nothing automatic is planned at the moment ...

|
|
| I think the above consistency checking might be the advantage of a
| separate Metacello supervising process over just using Gofer loads (
| which without being too familiar with it I assume would not provide
| these features)

There is certainly room for additional tools in this area, but beyond providing raw data I don't plan on venturing too far into this territory ... the analysis and decisions that Metacello currently performs during a load is pretty straightforward and simple...

Dale

Dale Henrichs wrote: Just to clarify - I had meant only a manual mechanism to resolve the
issue - eg #override:.... - which actually Metacello might already have Yep. I meant only reporting - not any automated decision making.
> Dale
>
>