[squeak-dev] Seaside, Squeak4.4, SqueakMap and Metacello, or Why Software Configuration Management is Important (war: Re: [Seaside] New catalog entry for Seaside 3.0.3)

Dale Henrichs dhenrich at vmware.com
Thu Mar 7 22:43:16 UTC 2013



----- Original Message -----
| From: "Frank Shearar" <frank.shearar at gmail.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Sent: Thursday, March 7, 2013 1:51:48 PM
| Subject: Re: [squeak-dev] Seaside, Squeak4.4, SqueakMap and Metacello, or Why	Software Configuration Management is
| Important (war: Re: [Seaside] New	catalog entry for Seaside 3.0.3)
| 
| On 7 March 2013 21:20, Dale Henrichs <dhenrich at vmware.com> wrote:
|
| > There are some basic rules that Metacello follows for loading packages:
| >
| >   1. If the specified package version is already loaded in the
| >      image, nothing is done
| >   2. If a later version of the package version is already loaded
| >      in the image, nothing is done
| >   3. If the specified package version is present in the package-cache,
| >      the package is loaded from the package-cache
| >   4. If the specified package version is found in one of the repositories
| >      listed for the package or project (multiple repositories may be
| >      specified) the package is loaded from the first repository it is found
| >      in (search order of repositories is not guaranteed)
| >   5. throw an error
| >
| > If one doesn't specify an explicit package version then the "latest version
| > of the package" is loaded. The Gofer sort order for packages is used to
| > determine "latest version". In this case, all of the associated
| > repositories are unconditionally searched for the "latest version", but
| > once the "latest version" is determined, the above listed rules are
| > applied.
| >
| > If a package is dirty, a notification is raised and if handled one can
| > choose to override the dirty package. The default action is to skip
| > loading over dirty pacakages.
| >
| > The rules for loading configurations is similar to packages except for a
| > couple of exceptions:
| >
| >   1. If the version being loaded is blessed as #development, then a new
| >   copy
| >      of the configuration is loaded from the repository.
| >   2. If you request a version that is not present in the loaded
| >   configuration,
| >      then an attempt is made to load the latest version of the
| >      configuration
| >      package from the repositories associated with the configuration and
| >      then
| >      the version lookup is tried again.
| 
| How does one specify the repositories in step 4? I know that a
| ConfigurationOf can say "find these in this project on SS3", which
| is... problematic. Well, it's fine as a _default_, but you need to be
| able to override that. And I know there's #overrideRepositories: but I
| thought that wasn't quite the thing that I was looking for?
| 
| I realise I should know all this stuff already. My apologies for forgetting.

Frank,

I kinda figured that would be where you were going, but covering the basics is important ...

I agree that "it's fine as a _default_", but to do so requires that one provide a means for managing the mapping between repositories and packages independent of the configuration. Without being present in a base image by default it is hard to provide such a mechanism:)

The Metacello Scripting API has an independent project registry, where you can identify which repository should be used with which project. I'm still working through some issues so I haven't released the Scripting API into the wild, but I am looking at the next major release of Metacello to directly address your needs ...

Dale


More information about the Squeak-dev mailing list