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

Anton van Straaten wrote:

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

Only if you think of (require (planet ...)) as an operational 
specification for how to retrieve a package. If you think of the require 
planet spec as "the planet package named X written by user Y" then it 
doesn't seem strange at all (at least it doesn't seem that way to me ...).

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

Yeah, you've missed a major feature of PLaneT :) If you write (require 
(planet ... ("usr" "pkg" X Y)) where X and Y are numbers, you're NOT 
saying "get version X.Y of the library," you're saying "Get a version of 
the library that's totally compatible with version X.Y" -- in other 
words, any package that implements version X.Y's entire interface and 
behaves in a compatible way. (PLaneT's rule for what's compatible with 
what dictates the version numbers, which is why I don't let people 
choose version numbers for themselves.)

Given that, I actually think it's a totally reasonable thing to be 
writing down in source code -- you want to be able to look at the 
library's spec and be able to easily predict what its interface will be, 
so it doesn't make sense to split the necessary information to figure 
that out into two separate files.

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

Mirrors are sounding more and more like a good idea to me. I'll be in 
touch --

-jacob