goran.krampe at bluefish.se wrote:
> Avi Bryant <avi at beta4.com> wrote:
> > We really, really need dependencies in SM - I'm tempted to add them in 
> > the quickest and dirtiest way I can and then hope the community bullies 
> > Gsran into including them even though they're not done "right"...
> 
> I think that would be an unwise course of action. :) Seriously -
> whichever solution we pick is going to be built upon really, really
> quickly and then we will have a really hard time moving to something
> else.
> 
> So IMHO it better be "right enough" from the start.

Good point.

A simple thing that seems to work is to give every card a "Depends"
field that lists a number of other packages.  It is assumed that
packages with the same name are compatible; thus if you make
incompatible changes, you must change the name of the package.

The algorithm in the SqueakMap browser can be as simple as follows:

	packagesToCheck := OrderedCollection with: requestedPackage.
	neededPackages := OrderedCollection new.

	[ packagesToCheck isEmpty ] whileFalse: [
		package := packagesToCheck removeFirst.
		(neededPackages includes: package) ifFalse: [
			neededPackages add: package.
			packagesToCheck addAll: package depends ]. ].
	
	neededPackages reverseDo: [ :p | p install ]


There are lots of improvements that can be made, but this simple
framework seems like plenty to get going.  Also, the improvements seem
to be backwards compatible.

At some point, it would be nice if people can grab packages from
multiple SqueakMap servers.  Maybe this is possible already?  It seems
good to add, eventually.  Then people can start making little
distributions, or "branches" as Andreas called them.

Another thing is that you can add more kinds of dependencies over time,
such as "recommends" and "conflicts".  You can also add alternatives,
like "Scamper depends on (URL or URI)".


-Lex