Monticello dependency handling
Avi Bryant
avi at beta4.com
Sat Feb 14 00:36:13 UTC 2004
On Feb 13, 2004, at 4:11 PM, Andreas Raab wrote:
> Hi Guys,
>
> I have a question about dependency handling in Monticello. Here's what
> happened: I put the entire B3D enchilada up on SqueakSource all with
> nice
> requirements stated. So, for example, I declared
> Balloon3D-Morphic[-ar.2] to
> depend on Balloon3D-Kernel[-ar.2] which in turn depends on
> Balloon3D-Constants[-ar.2]
>
> Then, Bert factored out some parts of Balloon3D-Kernel and put them
> into
> Balloon3D-Math, declaring an appropriate dependency between
> Balloon3D-Kernel[-bf.3] and Balloon3D-Math[-bf.1].
>
> However, trying to load Balloon3D-Morphic[-ar.2] still results in
> Balloon3D-Kernel[-ar.2] to be loaded. The question is: Is this
> intentional
> or a bug? If it's intentional, is there a way to declare a "lazy
> dependency"
> between packages which basically say "I don't care which version -
> just the
> latest one"?!
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.
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...
Incidentally, the "modified" check is awful right now - it will only
notice when you add or modify methods (and not add or modify classes,
or remove anything, or recategorize, etc). The
SystemChangeNotification stuff should fix this. Or maybe it should
check the slow and sure way when publishing (as if MC wasn't slow
enough already). Anyway, you may need to add extra whitespace to
methods or something to trick it into realizing that a dependency has
been modified sometimes.
Avi
More information about the Squeak-dev
mailing list
|