[Squeakfoundation]A bit about SM1.1 and dependencies

[goran.hultgren at bluefish.se]

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> goran.hultgren at bluefish.se wrote:
> > Daniel Vainsencher <danielv at 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