Daniel Vainsencher danielv@netvision.net.il wrote:

goran.hultgren@bluefish.se wrote:

...

Daniel Vainsencher danielv@netvision.net.il wrote:

...

Ok, just to show what I mean. Suppose I make a package type that holds a single method that goes something like ^#((RBModel 1.09) (RBGUI 1.06) (RBTests 1.05))

Then I write a service that loads this kind of package, and does packagesList collect: [:packagePair | SMSqueakMap loadPackage: packagePair first version: packagePair second].

Or maybe something a little more complicated, but you can see where I'm going... I don't need much more support.

Ok, this looks to me like "virtual packages". A package that has no content and loads specific versions of other packages. In fact - this is a "static load script" given my previous terminology. (Static in the sense that it will always result in the same package releases being loaded)

Not exactly - note that the code interpreting the list is outside the list, in a service. The code here is just a way to store the instructions.

Sure, but what real difference does that make? It is still a list of specific releases of other packages to be installed. Or?

...

But this plan doesn't AFAICT make it possible to have multiple possible configurations for RB. I assume that the virtual package/load script you described above would be "RB".

Actually it does - there's nothing stopping me from concurrently also publishing another package that also specifies the RB Components, at different versions. For example - ^#((RBModel 1.1)(RBGUI latest)(RBTests latest)(RBRewriteRuleEditor latest))

Sure, I understand that you can publish several different "load scripts". But that would in fact be *different* packages. Of course you would give them names like "RB cool" and "Another RB" etc. But that wouldn't help the dependency engine at all.

Let me reiterate: I want to be able to have different working configurations for one specific package release. For example, one "certified working configuration" is that RB1.2 works if SmaCC1.1 and SUnit3.3 are in the image too. BUT... RB1.2 may also be able to work just fine with SmaCC1.2 and SUnit3.3. That is another fully valid configuration for RB1.2.

The idea here is that an engine can analyze these multiple configurations. And adding a new configuration (registering a Resource and linking it to RB1.2) does not change the version of RB.

could represent the right configuration for someone that want to play with the latest GUIs, but using a known stable model. The two can definitely coexist - each is it's own package (I don't know what you mean by virtual), and even be authored by different package maintainers.

Yes, I fully agree that this is useful for exactly the thing you describe. But that is a "load script" package. It is not what I want to have for resolving complex dependency networks. They are two different things and they are needed both IMHO.

...

It would also mean that you need to make a new version of RB if you want to change the dependencies for RB - so you get "cascading version changes" - package Y is released in a new version and X depend on it so must also be released in a new version etc. etc.

No, why? The only time I'll have to update depedencies, is when I have a stable configuration, and I've decided that a newer version deserves to be point to in it. And I don't see many ways to go around that...

What? I didn't understand this. Ok, let's say you have registered a "load script" called RB version 1.0 that contains information about what other package releases should be loaded - package X1.1 and Y3.4.

And then I release package X in version 1.2. You realize that, hey - RB works dandy with this newer release of X. So what do you do? Ah, you need to *change* package RB. And if you change it then you better change the version too.

In my scheme you would simply just register another configuration and link it to RB1.0 - this simply says: Hey, I just tested RB1.0 with these packages too and it still works. So the dependency engine now has two working versions of X that it can choose from without making RB1.0 go bonkers. And that is very good since package Z that I want to use together with RB1.0 may actually *demand* X version 1.2.

Well, I have been describing these things so many times now that I simply need to implement them. :-)

I mean - it was you who pushed me in this direction by saying that the dependency information should be *outside* the packages in order to be able to have them evolve independently. Those emails we exchanged has influenced my model a lot. And now you are arguing IMHO in the opposite direction. ;-)

Sidenote: I did run my model by Roel Wuyts, Doug Way, Stephen Pair and several others I can't remember right now at OOPSLA and they all liked it. This also included the draft on how the dependency engine will use this information to resolve complex situations and my concept of "stretchable dependencies".

regards, Göran