[plt-scheme] package management thoughts

On Mon, 10 Mar 2003, Neil W. Van Dyke wrote:

> I wonder whether packages should be *required* to use contracts before
> they can be shared through CSPAN.  Requiring contracts might pose a
> significant barrier to some good packages being shared, given the
> diverse and eclectic senses of code aesthetics among the rugged
> individualists that are Scheme hackers.

Just to clarify, I don't think everyone should be required to specify
contracts, only that if module authors provide contracts then when users
have one piece of code that requires lib-A version 1.13 and another that
requires lib-A version 1.17, CSPAN will know that the cached copy of lib-A
version 1.37 actually satisfies both dependencies. If not, it will make
the user have three copies.

> I think "the author says it is" is the more important criteria,
> optionally backed up by a combination of contracts, package test suite,
> test suite of code that uses the package, and "wait a few days to see if
> this new version makes any early-upgraders complain."

I agree with you in principle: since we can't do a complete job of
ensuring that upgrades don't break things, we might as well let module
authors do what they want and try to encourage them to have enough
metainformation that hopefully somebody can figure out what went wrong
when something does. The question in my mind is just whether this is
absolute: I think of contracts as basically the minimum amount of
information we can usefully require, and I also think it can go a long
way in terms of allowing users to figure out what module is
responsible when something goes wrong. If contracts are not required,
I don't see any hope whatsoever of the software detecting upgrade errors
and we'll just have to hope users will be able to figure out that when
their software breaks it's because of an upgrade error. My gut reaction is
to say that's not acceptable, but maybe I'm wrong.

> If we generally trust the author not to often break things, and I think
> we can, then the other critera can be seen more as redundant safety
> checks -- something that is done as a matter of good practice by a user.
> However, the user should be able to override the checks easily, e.g.,
> the update tool might say, "Update of package Foo from 1.1 to 1.2 has
> the following 2 contract regressions: [...] Update anyway? (y/n)"

(We can't actually check the contract violations statically in general if
I understand them correctly -- we have to wait until they're broken.)

> This automatic flowing-in of updates would occur only in response to
> explicit user invocation (e.g., user selects the "Update From CSPAN"
> DrScheme menu item or executes the "cspan update-all" OS shell command)?

Yeah, only in response to explicit user upgrade requests.

-jacob