This post is LONG, but it explains how I intend to deal with
dependencies in SM.

"Stephen Pair" <spair at acm.org> wrote:
> Ned Konz wrote:
> > Actually the idea of configurations (sets of package to load) is
> > definitely part of Goran roadmap (He's written about it on the list
> > before).
> >
> > I think it'll probably turn out both pretty simple, and very, very
> > useful.
> >
> > One small problem with using scripts is composition - how do you handle
> > a script that loads two scripts, that have a shared requirement? with
> > scripts, you load it twice. Configurations should handle that better.
> >
> > Daniel
> 
> I'm not suggesting that load scripts would solve everything...just that they
> would be useful.  DVS doesn't solve all the thorny issues of packages, bug
> darned if isn't incredibly useful.
> 
> But, regarding this specific issue, I would not write any load scripts that
> loaded other load scripts.  Load scripts would only load packages (which
> shouldn't be loading other packages).  In this case you would have a lot of
> cases where load scripts were duplicating entire sets of packages (so no
> reuse), but on the other hand it keeps things simple and dumb until
> something better can be implemented.
> 
> - Stephen

Let me share the solution I am mulling over in my head for this. I have
been bouncing these ideas on Daniel, Ned, Doug, Roel and more. It goes
like this:

First, I want to introduce the term "package release" meaning "SSP 1.2".
A specific version of a package.

There are IMHO two distinct problems we want to solve:

1. To be able to post a "load script" (earlier I called this an "image
configuration" but that was maybe a tad too specific) that when
installed installs numerous other package releases in a specified order
into the image. This can be used for:
	1. Distros. A full mega image with whatever you like to distribute.
	2. Kernel building. The load script will then act as a Make file to
load packages on top of the microkernel image from Dan and the boys.
	3. Tasks. A load script can easily install a whole bunch of stuff that
someone thinks is a good "bunch of stuff" to have for a specific task.
Like "Web Application Development" including Seaside, Comanche, SSP etc.

2. To be able to describe the minimal requirements a package needs in
order to function. I call this a "package configuration". Given a query
of for example a set of packages we want to install, we can traverse
these published package configurations and figure out what other package
releases we need to include and if there are conflicts etc.

Ok, what is a "load script" then? Well, as some of you have already
described it is simply a .st file that uses the SM API to load
packages/package releases into the image. Having it as a script gives us
full flexibility - we can install a package release, patch it up, fix
some nuisance, load the next etc. It also makes a "load script" nothing
else than a package.

But currently SM can only load packages and not specific package
releases. That is why we need to add support for that. When we have that
we can probably write:

SMSqueakMap default installPackageNamed: 'SSP' version: '1.0'

...or something similar. If we follow the convention that a package
release is immutable (we can't really promise that today since the
actual packages aren't stored at SM) this would let us create
"immutable" load scripts too. If it only loads specific package releases
in a specific order then the end result will always be the same.

Now - a load script can also do dynamic stuff like for example load the
newest available package or ask the user for more direction etc. So, we
would probably like to distinguish between a "dynamic load script" and a
"static load script" or something like that. Still, just a category on
SM so the "load script" maintainer gives us his word.

Ok, so a load script is nothing more than a .st package with a few more
categories on it. Neat! The only thing missing from doing this today is
the unability to specify a specific package release. But otherwise this
is doable today - and I have already added categories for this!


Fine, what the heck is a package configuration then? It is a tested
minimal setup for a specific package release to work. So it goes
something like this in english:

"I Göran Hultgren have verified to my abilities that package release
Mungo 1.3 works fine with minimal required package releases Bimbo 2.4
and Zingo 1.02."

Notes:
1. A package configuration is not a script. It is declarative. Otherwise
we can not use them for dependency analysis and conflict detection etc.
2. For a given package release (Mungo 1.3) there can be numerous package
configurations by different people - the maintainer of Mungo but also
from dope heads like Göran Hultgren.
3. A package configuration is published by a person. You can choose to
trust him/her or not. Or you can choose to only trust the maintainer of
Mungo and thus ignore package configurations from other people.
4. A package configuration is a tested setup for one specific package
release. The above does not say if Zingo works ok, only that Mungo works
according to Göran.
5. A package configuration *only* lists package releases, not packages.
That is after all exactly what Göran tested - he can not make any
promises for using Mungo 1.3 with Zingo 2.0.


Ok, given these package configurations we can traverse them and figure
out what other package releases are needed and if this presents us with
conflicts. And there will be conflicts! Since we yet typically can not
have Zingo 2.0 at the same time as Zingo 1.02 we will want to deal with
the conflicts. How? Well, if we add one more little thing this can
actually be helped a lot:

For each package release we let the maintainer categorize the new
release in respect to how much it has changed relative to the previous
release. I call this the "compatibility level" of a package release.
Given 6 levels (or more/less, I will not describe them in detail here)
we can then give the user advice like:

"Hey, Mungo 1.3 has a dependency conflict with Pingu 1.2. They both rely
on Zingo but Pingu has only been verified to work with Zingo 2.0.
According to the compatibility level of Zingo 2.0 it is categorized as
*compatible* (=level 4, changes have been made but the maintainer says
he hasn't changed the API so it should work), would you like to use that
instead?"

And then the user can say, hey - hit me. It could also have said that,

"Hey, Houston. We have a problem. Mungo 1.3 has a dependency conflict
with Pingu 1.2. They both rely on Zingo but Pingu has only been verified
to work with Zingo 2.0. Zingo 2.0 is categorized as *non compatble*
(=level 6, the maintainer promises us that there is no chance in hell
that it is compatible, the API is totally new) so we are basically up
shit creek. Go have some coffee?"

Ok, this turned into a long post. Note also that the two concepts
outlined above have a nice property - since a "load script" is a package
it will be versionable. No strange things there.

And since a "package configuration" only refers to package releases
(which are immutable) they do not need to be versioned I think - it
there was something wrong with it, just change it. 
And a "package configuration" is not a package because they differ in a
few important ways:

1. They are not installable code. They do not refer to something
downloadable etc.
2. They are connected to a specific package release. That is not
something a package is.

etc. So this is a new beast. But load scripts are not.

Anyway, how does it sound?

Daniel has been bugging me with trying to unify these two concepts but I
like them separated and simple. Note that a "load script" can of course
use the package configurations through the API of SM. Note also that a
load script can of course use other load scripts - they are after all
just packages. In that respect only our imagination sets the limits.

Note also that a package configuration is not "composable" or anything -
it's a simple list (possibly ordered) of package releases, nothing else.
Maybe we could let it have a Composite pattern and let it refer to other
package configurations - but perhaps it will just make things
complicated.

regards, Göran