Hi Avi,

> It's intentional, but you may have uncovered a bug in the intent (I did
> *say* this dependency stuff was provisional, right?).  The use case I
> was picturing is that you would end up with one top level package
> ("Balloon3D") that has (transitively) dependencies on all the rest.
> Then when you want to publish, you publish *only* the top level
> package. It will recursively make sure that all of its required
> packages that have been modified (or that have required packages that
> have been modified - I need to check that it actually it does this)
> also get new versions published, which will have updated dependencies.
> So Bert would have published a new version of Balloon3D, which would
> have triggered a cascade of new versions of everything from Math on up.
> Loading Balloon3D-Morphic-ar.2 would still get you
> Balloon3D-Kernel-ar.2, but there would now be a Balloon3D-Morphic-bf.3
> that depends on Balloon3D-Kernel-bf.3.

Hm ... this will work as long as every developer has indeed the master
package loaded. But it won't work if you have the package loaded only
partially (and I actually think Bert didn't have the full enchilada).

> So that was the intent, but please poke holes in it.  The problem with
> doing "lazy" dependencies is it's never very clear what the "latest"
> version is, or how much tolerance to have (do you really want
> Balloon3D-Morphic-ar.2 to load Balloon-3D-Kernel-ar.765 some time in
> the future?). And, generally, that feels like a release issue and
> should be handled by SM - if you're using dependencies in MC it's
> between parts of a package that you wholly control and so hard links
> *should* be manageable.  But there are clearly still some usability
> issues to work out.  In particular I don't know how to handle the case
> when you're only working with a subpackage and don't have the "whole
> enchilada" loaded...

For the relation between SM and MC I would argue for precisely the opposite
direction - MC is my working environment as a developer, SM is for releases
to users. For a (SM) release, I would indeed expect that the dependencies
are strict whereas for my working environment I would expect it to
automatically fetch the latest versions.

That said, let me throw in a word about "how lazy". I've been thinking about
the "author" in MC packages and it seems pretty clear that an author's
version(s) define an independent life-line from that of any other author -
or in other words, a branch. So one way to deal with this issue is rather
than automatically giving each developer its own (implicit) branch to make
this handling a little more explicit. Here is how I would imagine this:

If we replace the "author" in the MCPackage by a "branch" we would have a
way for the developer to decide which branch to work on. By default it would
be their own branch so you would work in precisely the same way you're doing
right now. However, you may as well have any number of other branches which
you can explicitly commit against. So for Balloon, I would have a "main"
branch which (upon saving) Bert could decide to use instead of the
default -bf branch.

For dependencies I would probably opt for having a "release commit" which
really freezes the particular dependencies. So if I do a release commit
against Balloon3D-All-main.42 then it would depend on, say,
Balloon-Kernel-main.22 and Balloon-Constants-main.2 whereas for a "regular
commit" it would merely say that Balloon3D-All-main.43 depends on
Balloon-main.* and Balloon-Constants-main.*

For all practical purposes I would expect this to work rather well - a
release is somewhat special anyway and since we have SM as the place for
releases MC could concentrate on the developer workflow instead.

Oh, and two more things: When dependent packages are loaded, the associated
repository isn't available in the MC browser. E.g., if you load
Balloon3D-All the repository for the other packages seems to be lost.

Secondly, mind to use a tree view instead of the current list for
dependencies?! ;-) It would be much easier to look at dependencies if you
could just open the tree. Code is attached.

Cheers,
    - Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MCTreePane-ar.1.cs
Type: application/octet-stream
Size: 4792 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040214/2866bd47/MCTreePane-ar.1.obj