[plt-scheme] package management thoughts

At Wed, 12 Mar 2003 21:43:02 -0500 (EST), Paul T. Graunke wrote:
> I'm not too fond of the use of contracts for compatibility, at least not
> unless there is a way to override the behavior.  In addition to the weakness
> Eli pointed out, I may wish to provide more precise contracts in later
> versions of a library.  For example,
>   fake-tcp-listen : nat -> fake-listener
> consumes a network port and returns something like a tcp-listener.
> Actually, the port number must be > 1024 and < 2^whatever, so I
> refine my contract in the next version.  

Contracts can certainly provide this kind of thing. That corresponds
exactly to the contract checking you want for behavioral subtyping and
we can do that (OOPSLA and FSE 2001 papers from my web page give more
details, but the basic idea is that you can just check both contracts
and ensure they are compatible when a function is called or returns.
Compatability failure and pre-condition failure are separate things and
can be handled separately, assigning blame to right place)

> I would rather see
>  -  each module come with a test suite
>     It could be (lambda () 'I-pass) for careless folks.
>  -  When module A requires module B, updating the link from A to B to
>     use a new version of B is okay iff A's testsuite still passes.
>     Multiple require links may need to upgrade simultaniously.

It's my opinion that planet will not work if we require too much of the
code providers or planet code (re-)users. The overall design goal is to
allow things like you suggest without making them mandatory, and to
keep the overall process very lightweight. If all you want to do is
contribute some code, just push the button and off it goes. If you want
to provide more (test suite, docs, contracts, etc) that should also be
easy to add. Above all, we must never requiring extra wierd knobs that
only sophisticated PLTers would know how to set (eg, forcing people to
figure out how to call `pack' to build a .plt before they can
contribute would be right out)

> I do think it would be good to be able to roll back after an
> "up"grade.

Yes, that is planned, too.

> One problem is that a packages with N imports with M more recent versions
> of each import has M^N possible upgrades.  Maybe the best bets to try
> are eitherh no upgrades, all new upgrades, or all upgrades that are
> supposed to be compatible or have contracts matching or some heuristic.
> I still want to run the test suite of A even if B' and B have mathching
> contracts and are supposed to be compatible.

We've imagined a scheme where the require'r specifies what versions are
acceptable to it, much like what Mike Sperber proposed. I'm not sure we
need the full generality of what he was suggesting, but something very
similar. So, for example, you can say "I want at least version 1.2, but
no more than 1.8", and the code you get is the latest version available
when the upgrade button was last pushed.

The rollback would only roll back to states you have had on your system
at some point, the idea being that you only really want to roll back
when you upgrade and things stop working. Along with this, we can
synthesize the current state of the planet in a given system as part of
a bug report, so that developers can put in the same code as the bug
reporter had when they had the problem, and have a better chance of
reproducing reported bugs.

Robby