location of package dependencies

Lex Spoon lex at cc.gatech.edu
Tue Jul 29 14:36:17 UTC 2003


goran.krampe at bluefish.se wrote:


> > One, we ought to have a way of putting multiple packages in one file. 
> > Combined with Monticello's ability to figure out dependencies, this 
> > gives us a good way to distribute applications, which may consist of 
> > several packages.
> 
> I definitely don't agree. This would really conflict with the current
> plan for dependencies/SM etc.
> One of the big things with that plan is that dependency information
> should NOT be inside the packages etc.

Why not?  If package doesn't know what it needs, then who does?

Do you mean that *concrete* dependencies are not in the package?  That
sounds like a good idea.  But what's wrong with abstract dependencies:
"I need some package that provides 'web-server' "  ?

In any case, where *do* the dependencies go?  If I upload a package,
where do I upload the list of packages my package depends on?  Surely
it's not up to someone else to figure out the list of dependencies.

Is it supposed to be automatic?  How would that work?  It seems that
human intervention is at least sometimes necessary, because you may rely
on semantic differences.  As an example, a package may depend on
RBParser, but specifically to require a new enough version that {}
syntax is supported.  Or more telling, it may rely on one particular
flavor of TimeStamp.

Giving a package a list of dependencies is simple and would at least be
fine.  There's no particular reason to settle for "fine" of course, but
what's the plan?  I missed this.

Lex



More information about the Squeak-dev mailing list