Dependencies, Squeak Code Control [proposal, long] (was: [TFNR][REPORT]Where are we?!)

gohu at bluefish.se gohu at bluefish.se
Tue Nov 18 22:10:27 UTC 2003


Hi all!

[SNIP]
> Personally, I think that Packages and Configurations are all that is
> really needed, and it's really simple.  A package is some body of code
> (that has certain implicit dependencies) and a Configuration is a
> specification for loading a set of package versions (where the
> configuration may specify any number of packages or configurations).

This is almost as I have planned it. Though I didn't think a "package
configuration" could reference another configuration. I need to think
about that one. :)
> Configurations and packages can be versioned.  Configurations can be

Ah. Are you sure that configurations *need* to be versioned? In my model I
went even further and thought that, no - there is no real point in
tracking evolution of a package configuration - they just "are".
And perhaps, since my "package configurations" can't reference other
"package configurations" then versioning them turns less interesting.
So my proposed model is IMHO simple. It only has *package releases*
(Comanche 6.1, Comanche 6.2 etc) and *package configurations* which are
Sets of package releases attached to a specific package release.
In other words again:

A package release is one piece of code. If you change the code you make
another release of it. The package release holds the download URL.
A package configuration is the Set of other package releases (say Comanche
6.2, Breakpoints 1.2) that a specific package release (say Seaside 2.1)
*has been verified to work with* by someone.
A package configuration has no order (it is a Set of package releases that
*need* to be there, not a load script) and it should only specify the
package releases *needed*.
A package configuration is "attached" to a package release. A package
release can have multiple such attached package configurations. If a new
release works with the previous release's config - then we can easily just
copy it.
So, enough words - here is the model written in this syntax:

Package release
  Package config
  Package config
  Package config

So this is how it can look with examples:

Seaside 2.1 owned by Avi
  (Comanche 6.1, PackageInfo 1.0, Monticello 49) owned by Avi
  (Comanche 6.1, PackageInfo 1.0, Monticello 38) owned by Avi
  (KomHttpServer 6.2, PackageInfo 1.0, Monticello 38) owned by Goran

HttpView 1.0 owned by Goran
  (Comanche 6.1) owned by Goran
  (KomHttpServer 6.2) owned by Stephen

HttpView 1.1 owned by Goran
  (KomHttpServer 6.2) owned by Goran


Ok, let's have a look. I can easily see that Seaside 2.1 has been tested
by Avi and verified to work with Comanche 6.1, PackageInfo 1.0 and
Monticello 38 or 49. I can also see that the untrustworthy Goran claims it
also works with KomHttpServer 6.2 - but what does he know, right? Might
not want to trust configs by others than the author.
HttpView 1.0 works with either Comanche 6.1 or KomHttpServer 6.2, at least
if we trust Stephen. The newer 1.1 version has only been verified to work
with KomHttpServer 6.2
So... easy? I think so. Now, what happens if we implement a "resolution
engine" on this? Let's say I tell it to install Seaside 2.1 and HttpView
1.1. The engine then gets:
  ((Comanche 6.1, PackageInfo 1.0, Monticello 49) owned by Avi
OR
  (Comanche 6.1, PackageInfo 1.0, Monticello 38) owned by Avi
OR
  (KomHttpServer 6.2, PackageInfo 1.0, Monticello 38) owned by Goran)
AND
  (KomHttpServer 6.2) owned by Goran

Ok, you will then need KomHttpServer 6.2, PackageInfo 1.0 and Monticello
38. But hey - I want Monticello 49! Well, the engine then says - fine, but
then you need Comanche 6.1, KomHttpServer 6.2 and PackageInfo 1.0 - OOPS!
Here we actually discover a little extra thing we might need - the ability
to say that Comanche 6.1 and KomHttpServer 6.2 conflict with each other.
An attribute of the package release itself I think.
The engine might say - "but if you back down to HttpView 1.0 then you can
have Monticello 49, PackageInfo 1.0 and Comanche 6.1 instead."
Anyway, I hope the above model seems simple and capable. It is much like
Stephen's (but configs don't have versions and can't refer to other
configs - would be interesting to hear Stephen's words on that). And it
also needs the "anti-matter" mechanism of course. :-)
Well, I have written far too much about this over the last year/years. I
am just going to implement it and see if "code talks".
regards, Göran

PS. Right, there is also the backwards-compatibility level thingy that
makes the picture complete and gives the user+engine better ways to
explore possible combinations.




More information about the Squeak-dev mailing list