[Squeakfoundation]A bit about SM1.1 and dependencies

[goran.hultgren at bluefish.se]

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> Ah, I see what you envision now. I don't actually see changing the
> configuration package as a problem - I do trust you'll give an api to do
> this soon, and then code can do it for me. And as you say, it might be
> wise to have alternative configurations for the same package. There's no
> conflict - the alternatives can certainly live inside the package.
> 
> We agree the depedencies should be outside the code packages, the
> difference is whether to keep them in a "special place" - resources, or
> in packages themselves. 

Well, this is not the only difference. Your model limits the number of
available configurations for a certain package to 1. And no - it doesn't
help that you can register more different "load scripts" - those are
*other* packages. The only way to know that they are actually different
configurations of *the same* package (RB in our example) is by letting a
human look at the package names and guess.

And I maintain my stance that your model has the problem of "cascading
versions" (well, you know what I mean).

> Simplest thing that could possibly work?

I agree that "load scripts" (which we already have) and the existence
package releases (which we don't have yet) would make some form of
dependency management possible. But then people would actually start
using that ;-) and later, when we realize that hey, this actually is a
bit too simple - then we will have an interesting battle to migrate to a
slightly more capable model.

I fully agree with STTCPW - but only during development. I don't really
think you can apply the principle (at least not without looking at the
consequences) to systems actually being deployed. Which SM is.

> > It is not what I want to have for resolving complex dependency networks.
> > They are two different things and they are needed both IMHO.
> Aha - we may be addressing different requirements. I'm addressing
> precisely this problem - I want packages to be modular, I want users to
> be able to load a package with it's prerequisites, I want maintenance of
> configurations to be separate from maintenance of code. Either solution
> does all of these (haven't changed my mind about any of these).

Ok, I want a bit more. :-) I am aiming (in the end) for a conflict
resolution engine that given this question:

Hey, Mr Engine - can you please load me up with the latest possible
Seaside, Cassowary, Magma, Traits and experimental new Collection
hierarchy?

Mr Engine mumbles for a while and then answers ok, it looks feasible but
I only found one configuration for Seaside that works in this scenario
and that is a configuration published by Daniel Vainsencher who is not
the maintainer of Seaside. Do you trust Daniel? Ok, then I will use
package X1.2 instead of X1.1 that Seaside needs (because Daniel has
published such a verified configuration for Seaside). Ooops, almost
forgot - there are three different configurations for Magma and they all
require package Y1.1 but Traits requires Y1.2. But don't worry - it
seems that version 1.2 has been classified as "should be backwards
compatible, only bugfixes" - would you like to take a chance regarding
Traits and use 1.2?

Anyway - the above little scenario both relies on my multiple configs
for packages AND the thing I call "stretchable dependencies". Didn't we
discuss them earlier? I think we did. The idea that the package
maintainer classifies a new release "how backwards compatible" it is. I
have 6 levels written down somewhere and the first 2 are machine
detectable.

> I'm not looking for anything more complicated, among things because I'm
> hoping to make a working release within days of having an SM that
> supports package releases, for many good reasons mentioned before.
> 
> What additional needs are you addressing? (elaborate on complex
> analysis...)

Well, the description above covers it I think. I want multiple configs
per package release linked to the release. Anyone can register a config
for a package release. This also avoids the "version cascade problem"
(btw, Resources are NOT versioned in my model). I also want the
backwards compatibility classification of package releases (just a
simple dropdown menu will do fine) in order to make the conflict
resolution "human aidable".

> > > And I don't see many ways to go around that...
> > What? I didn't understand this. 
> I'm simply pointing out that when a code package is updated, a human
> will have to evaluate it to update the configuration. That's the main
> thing humans maintaining configuration (not code) will have to do, and
> that's the same between both proposals. 

Well, no. :-) (or perhaps I am daft)
When I change a configuration for package X (or add one) I *do not* need
to change the version of package X. But you do. Still a major difference
IMHO.

> How that translates to changes in the metadata itself, I don't care much
> about - it can be mechanized, either way.

I don't follow you. It is IMHO a big difference that I care about
because it will create "ripples" in the map which in turn will make
packages conflict even when they in fact don't.

> I think the models we're proposing are very similar, mine is just
> minimal and maybe a little crude, but I think it can take us a pretty
> long way.

I agree in principal but I think we should aim a little big higher from
the start here in order to win out in the long run. :-)

> And the two systems can definitely coexist, and probably even
> interoperate (you can depend on my kind of package, a vice versa).

Yes. As I described before - you are simply aiming to handle
dependencies through "static load scripts".
Of course you will be able to do that as soon as package releases are
available.

And hopefully not too many will follow your lead and produce a big
complicated mess of load scripts that conflict with each other all over
the place until I get my model working. ;-) ;-)

regards, Göran