location of package dependencies

Daniel Vainsencher danielv at netvision.net.il
Tue Jul 29 15:46:30 UTC 2003


Well, the idea is this - dependency information doesn't have the same
life time as the code it applies to, and there is no neccessity for it
to be generated at the same time or by the same person. Therefore, it
should be possible to update dependencies independently of package
updates.

For example - suppose SmaCC is declared by it's author to depend on RB
because the RB includes some specific extensions that SmaCC needs.
Suppose those extensions are then incorporated in a later version of
Squeak. The dependency information has changed, though the SmaCC code
hasn't. It should be possible to update the dependency information
somewhere, without repackaging or modifying the SM entry. 

Suppose the SmaCC maintainer is no longer interested in it, but one of
its avid users has noted the dependency change. This user should be able
add this information.

Therefore - hold dependencies separately from package contents. Here
there are two different concepts. 

The trivial one, "load scripts", says that anyone can act as a
"distributor" for a package, by writing a load script that fulfills its
dependencies, as he sees them. This can be implemented as soon as
package releases are supported by SM.

Goran has a different concept, in which dependency information would be
a separate kind of entry in SM, which could be inserted and modified by
different people. Then the dependency resolution process would be part
of SM machinary itself. If I mistate Goran's views, I'm sure he'll
correct me.

In either case the declaration of dependencies is generally done by
humans (though some tool could imaginably be plugged in later). Quite
often, the author will write the initial dependencies (unless he's
really lazy, and his package is popular enough that "someone will do
it"), but the process of maintaining the dependencies won't depend on
him exclusively.

Daniel

Lex Spoon <lex at cc.gatech.edu> wrote:
> 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