[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)

Frank Shearar frank.shearar at gmail.com
Thu Mar 7 22:55:18 UTC 2013


On 7 March 2013 22:43, Dale Henrichs <dhenrich at vmware.com> wrote:
>
>
> ----- 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 ...

That's awesome, because I know this guy who can get code into Trunk? *cough*

We seem to have a bit of a chicken & egg here with the Metacello
Scripting API, where you want feedback before putting it into Squeak
trunk, and I can appreciate you not wanting your hands tied by
everyone scrambling to use your half-baked API. I wouldn't mind it
baking in trunk now just because it's nice & early in our release
cycle.

frank

> Dale
>


More information about the Squeak-dev mailing list