[Squeakfoundation]A bit about SM1.1 and dependencies

[goran.hultgren at bluefish.se]

Hi!

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> [I claim resources/links not needed for depedencies]
> =?ISO-8859-1?Q?G=F6ran_Hultgren?= <goran.hultgren at bluefish.se> wrote:
> > Well, I am having a hard time seeing where we should record our dependencies if
> > we don't have Resources. They *are* needed. At least given my plan. :-)
> 
> 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)

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".

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.

[SNIP]
> Ah, I see what you mean. I'd thought you were going to implement that
> RPC anyway, since the image do need to communicate anyhow. 

No, I have a greater plan lined up. :-) But we can talk about that
later.

> > > I have interest, and would be glad to help flesh out the services along
> > > the lines above. Whether that'd be as a part of SM for you to integrate
> > > or as a separate package - as you wish. It'll be very easy to specify
> > > that the UIs require both SM and SM Services after we get dependencies,
> > > so I don't see a problem... :-)
> > 
> > I will try to get it out this weekend and perhaps you could take over the
> > services part.
> 
> Cool.

Perfect. I will then aim for getting what I have got to you with some
explanation on what I was aiming for in the "services area" - but you
can of course ignore that and do what you like - just as long as it is
better than what we have now!

regards, Göran