[plt-scheme] PlaneT, plts and distributing software.

Jacob Matthews wrote:
> Noel Welsh wrote:
> 
>  > Some points:
> 
>  > The programmer has to decide at coding time to use libraries via
>  > Planet or .plts.
> 
> Just because I'm pedantic like that, I should point out that PLaneT
> and .plts are not competing systems; PLaneT is an automatic mechanism
> for distributing and installing .plts. So the issue is really between
> installing .plts from PLaneT or installing them manually.

Noel still has a point, though, that the decision to use PLaneT has to 
be recorded in source code, which has some not-so-ideal consequences.

First, using PLaneT seems to essentially "ghettoize" any collections 
that were retrieved via PLaneT.  All subsequent code that uses that 
collection has to use the PLaneT require form.

Ignoring the technical rationale for this for a moment, from the 
programmer's perspective, it seems a little strange, the tail wagging 
the dog: the delivery mechanism dictates the way it's used at the source 
code level.

Second, hard-coding version number dependencies in source code is a 
questionable tactic.  It may make sense in some scenarios, but in many 
if not most cases, it seems preferable to handle this external to the 
source code, as a configuration issue.

Otherwise, for example, an upgrade to an otherwise completely compatible 
later version of a collection requires modifying every source module 
which uses that collection.  Compatible upgrades are a pretty common 
occurrence, so this just adds overhead to upgrading, afaict (unless I've 
missed some major feature of PLaneT).

>  > So I suggest:
> 
>  > - remove the distinction between (require (lib ...)) and (require
>  > (planet ...)) (Yay, less typing)
> 
> Hm ... I'm not sure what you mean here. The distinction between those
> two forms isn't very easy to remove, and if it were it would
> necessarily involve making library requires bigger rather than making
> planet requires smaller. The only extra information the planet require
> form has over the lib require form is basically a little more
> structure in the name of the library -- "reduction-semantics" versus
> ("robby" "reduction-semantics" 1 0). I don't see how to get rid of
> any of those three extra pieces in general.

A level of indirection seems to be called for, so that explicit version 
number dependencies can be abstracted out of the source code.  A mapping 
would be necessary between the collection names specified by a program, 
and the version numbers, location, and retrieval mechanism for those 
collections.

While I'm blue-skying, this could also allow a level of indirection from 
filesystems, so that requires (or their replacement) can use logical 
names rather than weakly-obscured filesystem pathnames.  So something 
like (require reduction-semantics) might, via the collection 
configuration system, map to ("robby" "reduction-semantics" 1 0).

>  > - Implement a fault tolerant (i.e. distributed) Planet.
> 
>  > I feel the last should be undertaken by those who have expressed a
>  > desire for such a thing -- it would be quite some work.

This is not a point I'm too concerned about myself, but if there were 
more than one PLaneT server, fault-tolerance could be dealt with simply 
by having the client have a list of mirrors in its configuration, and 
trying one after the other.  That's a lot less work than my suggestions 
above.  ;)

I'd be willing to host a PLaneT mirror, BTW.  There's plenty of spare 
bandwidth on the servers that host LtU and the Scheme Cookbook.

Anton