Hi Lex and all!

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

Typically the author knows best but there may be different people
knowing about the dependencies. There may even be someone knowing more
than the author.

> Do you mean that *concrete* dependencies are not in the package?  That
> sounds like a good idea. 

Yes. I am aiming to have them in so called "resources" instead that can
be linked to package releases. Such "resources" can be either reachable
by URL (not very useful for dependencies) OR more importantly embedded
inside the map. Having them embedded in the map means that you will have
ALL dependency information available for all package releases available
on SqueakMap. This means that anyone can build a tool to analyze them,
resolve conflicts etc.

> But what's wrong with abstract dependencies:
> "I need some package that provides 'web-server' "  ?

Personally not much fond of those actually. Please read my ramblings
here:

http://anakin.bluefish.se/gohu/17
 
> In any case, where *do* the dependencies go?  If I upload a package,

They are meant to be in the map.

> 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

Not automatic. Perhaps guided by tools though. Written by Daniel. :)

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

Exactly.

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

Read at least one or two of my previous postings available on the URL I
gave above.
 
> Lex

regards, Goran