[plt-scheme] package management thoughts

I really don't have any idea of a general solution, so consider me as
just adding adding to the mess...


On Mar  6, Jacob Matthews wrote:
> 
> The package manager I've got in mind works a little like Debian's apt/dpkg
> system:
> 
> (require (cspan "mylib" "3.5"))

(Side question -- why is the "p" there?  It just sounds too much
similar to cpan.  (I generally dislike the cXan names, they all sound
too similar and one differentiating character is just too little...))


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

This sounds good but...

> The central question of the system, then, is what gets to be compatible
> with what.

...can there be a general solution to that that will work in a way
that doesn't discourage people from making more modules?  I don't
think that there's a sensible way for that -- even if you take an idea
world where people specify full contracts, you'll have to do some
analysis for the actual functionality used to know when a new version
is incompatible.  It's pretty common to find some higher level stable
interface, and then some lower-level stuff that was exposed for some
reason which is much less stable, or new functionality which you're
not sure about.

I'll use Swindle as an example (obviously...): an example of the first
case is a function like `change-class!' which I added to allow some
low-level tricks (making a class meta-class which is an instance of
itself) -- it is more likely to change than the more standard stuff.
An example for the second case is my new `collect' super-loop macro
which is still new and I'm not too sure about the syntax, so it might
still change.

So in general, I expect that normal packages that rely on Swindle will
not use these too (the first being too low level and the second being
too new), which means that they should continue working if the
interface of these things is modified.  But this is still not the
whole thing...  -- What if you use a function that had its interface
changed, it might be that the change is 'mostly' backward compatible,
like extending the regexp functions to handle ports -- but what if
some program relied on throwing an exception for such a case?  Or what
if some weird behavior that is hardly ever used is changed?

I just don't see any way around these things that don't lead to
breaking the simplicity principle (which I agree with you and Shriram
is very important).

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!