Frank,

I appreciate the offer, but I've got one or two outstanding bugs that I'd prefer to fix before letting the api out in the wild ... I've got a couple of folks using the api in their projects (which is why I know I've got these bugs) ... there are a couple of things that are in my queue in front of fixing these bugs. so .... but I see light at the end of the tunnel and don't want to push it out too far ... 

I know that getting the api into the trunk early is the best way to go about this, but I also need to make sure that I can be responsive when it is let loose into the wild:)

Dale

----- 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 2:55:18 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 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
| >
|