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

"Stephen Pair" spair@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

Brent Vukmer bvukmer@blackboard.com wrote:

Goran --

Are you planning to use something like Stephen Pair's VersionNumber package, to encapsulate version info? Of course that would create a

Yes. I have already talked with Stephen about that. No point in not doing it. But that will be the automatic number not changeable by the registrant. We also need a simple String so that people can still use their own schemes for version naming.

dependency of the SqueakMap package on another package... :)

Well, if I do it in one big swoop then we will have support for that, right! :-) Nice bootstrapping there.

I notice that right now SMCard>>currentVersion: expects a String. As we move deeper into package version dependencies/configurations/conflicts etc. it seems like Version objects of some kind might make for more informative debugging than just Strings.

Yes, but they are a complement - not a replacement. People still want to have a nice readable label. But internally we want to have a nice number like Stephen has implemented.

regards, Göran

Stephane,

you cite far too much of the original post. Please stop doing that, so I can read your posts.

Thanks, -Simon

"Stephen Pair" spair@acm.org wrote:

Göran wrote:

...

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.

If you design the API well enough the "load script" can be as good as an exclusively declarative syntax. For example instead of being so explicit in the load script:

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

We could write:

(PackageConfiguration new:

Comanche 5.0 SSP 1.0 Seaside 2.0 )) load !

Yes, I will consider this type of design. Note though that I don't want to restrict the load scripts much - I want them to be very flexible and instead let the "package configurations" take the hit of being strict and declarative and thus easily used for dependency analysis and conflict detection.

regards, Göran