[plt-scheme] package management thoughts

[Here's a summary of a private e-mail about CSPAN, the package manager I'm
working on. I figured the list in general would want to discuss the
issue.]

The package manager I've got in mind works a little like Debian's apt/dpkg
system:

(require (cspan "mylib" "3.5"))

or something like that will check to see if you've got a local copy of a
library compatible with mylib version 3.5; if so, it runs, if not it gets
it and recursively checks its cspan-dependencies, and a separate
management program will allow other apt-like functions (upgrade, etc).

The central question of the system, then, is what gets to be compatible
with what. The thoughts on the issue are that we ought to use simple
criteria: a module is compatible with a prior revision if

- Its functions have compatible contracts with the prior revision and
- The author says it is.

Obviously, we can't in general check the first property statically and the
second property has poor formal guarantees :), so it's easy to concoct a
scenario in which a module author upgrades a package and breaks it,
causing a cascading problem where a whole subsystem breaks. That is a
problem, but I think that we ought to provide ways of fixing it when it
occurs rather than trying to preclude it from ever happening. I think this
for a couple of reasons:

1) I doubt it will crop up all that often.
2) Adding rules to preclude it from occuring might be a cure that's worse
than the disease: I can't see any way that doesn't either remove important
functionality (automatic upgrades a la "apt-get upgrade") or place a large
enough burden on module authors that nobody would use the system (e.g.,
requiring module authors to specify precise behavioral constraints on the
libraries they use).

Simplicity is, in my opinion, one of the most important concerns for the
project: our primary goal isn't to provide a research problem, but to
provide a useful mechanism with which people can actually share their
code, so we need a system people can actually use without becoming
experts. We want the average case to be very easy: you write a normal
module and click a button and now it's shared with the world, or you find
a module on our web site and copy-and-paste a line into your program and
now your program uses that module, with all the bugfixes and everything
just automatically flowing in. If a problem crops up, hopefully cspan
detects it and provides enough information that someone can fix it.

This presupposes that conflicts won't frequently occur between modules
that we magically determine are "compatible." I'm convinced that a there
is a simple definition of "compatible" that will allow most upgrades to
retain compatibility with prior versions and that will make conflicts
between libraries we deem compatible rare in practice, but of course that
judgement is the key to the whole system's viability.

One idea I think is promising is to encourage module authors to
annotate all provided functions with contracts and to require that minor
revisions of a library not change any contracts in incompatible ways --
i.e., nothing other than adding new functions or weakening preconditions
and strengthening postconditions on existing functions. (Libraries that
don't have contracts are allowed, but every revision is forced to be major
revision that won't be counted as compatible with any other.)

That strategy allows a confused or malicious module author to specify
contracts in such a way that cspan won't be able to detect that an error
stems from version incompatibility when in fact it does, but I think that
problem will be solved without technical intervention: people just won't
use those libraries, because they're buggy. To cover all the bases, we'll
let requirers specify that they need a particular minor revision, but I
think that facility will rarely be used.

I'd love to hear people's feedback on this.

-jacob