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

Anton van Straaten wrote:

> [...] you're implying that you (the PLaneT maintainer) might decide to 
> replace the package I get when I use the numbers X and Y, because 
> you've determined that the replacement version is sufficiently 
> compatible (you said "totally", but I'm not sure how you propose to 
> determine that).  That, for me, is pretty much a deal-breaker all on 
> its own.  If I develop and test a system, there are many cases in 
> which there's no point in having the ability to distribute it without 
> its dependencies, if I can't be guaranteed that the exact same 
> dependencies that it was tested against are going to be pulled in, 
> even if it's installed years after it was first developed.

There are two  safeguards in place to protect you in this situation. The 
first is the linkage table: the first time a source file requires a 
particular planet module with a particular version, that exact version 
gets "linked" to that source file and it will always get exact package 
from then on, even if a new, better, compatible package becomes 
available. The user of the software has to explicitly say that they want 
your package to get relinked to newer packages if they want that 
behavior. Second, if for whatever reason you want to use a planet 
package but don't trust its maintainer to actually make allegedly 
backwards-compatible releases truly backwards-compatible, you can 
restrict your require-spec:

  (require (planet "file" ("usr" "pkg" 1 (= 3))))

means "exactly version 1.3, accept no substitutes." Similarly

  (require (planet "file" ("usr" "pkg" 1 (- 3))))

means "anything between 1.0 and 1.3" and

  (require (planet "file" ("usr" "pkg" 1 (4 8))))

means "anything between 1.4 and 1.8, but no higher or lower."

[These options don't seem to be widely known, but they've been in PLaneT 
since the very beginning.]

> I can see the benefit of trusting in PLaneT and, *in some cases*, 
> requesting "whatever you guys think is compatible enough with X & Y". 
> But that should be an option, not the only possibility.

I think that ought to be the default, and there should be ways to 
override the default ... that's why I designed the system the way I did. 
On the other hand, I think you're right that the client ought to be able 
to have some say in what planet package gets used to satisfy what 
dependency also (or more generally, anyone who doesn't want to edit the 
source code), and at the moment there's no good story for that.

> If every module in my program includes the same require statements 
> with the same X & Y values, I'd like to be able to centralize that so 
> that if I need to change X & Y, I can do it in one place.  Again, 
> there might be cases where embedding X & Y in the requiring module 
> makes sense, but I would see those cases as being for little scripts 
> and such, not for larger multi-module systems.

If you want to be able to centralize that decision, you can already do 
so --- see Robby's message.

If you want it to be centralized *by default*, that's got to be 
approached very carefully. One of the most important design principles 
of PLaneT is that it needs to be as simple as it can possibly be. I  
consider it critically important that you can copy and paste a single 
line from planet.plt-scheme.org into your program-- without even 
understanding what it means -- and have the system do the right thing. 
As time goes by, you shouldn't have to realize that the web page's 
require lines are all wrong and that if you really want to use planet 
the _right_ way you should've been doing something else entirely all 
along. That's not to say it's not a real problem, just that any solution 
has got to be very careful not to give PLaneT a higher barrier to entry.

;; ----

So at this point there are at least a couple concrete major feature 
requests outstanding for PLaneT, and a few more vague major requests:

Concrete:
1. Allow developers to store planet code in any directory they'd like 
and tell planet how to get to it, so they can test their modules as they 
develop them
2. Rearrange the server code to allow for mirrors, and then change the 
client so that it knows about them
3. There are certain situations in which planet-managed .zo files can 
screw up an upgrade or prevent you from working with two different 
versions of PLT Scheme at once until you run setup-plt -- this is a bug 
and needs to be fixed.

More general:
1. Give developers and users a better way to control what require spec 
goes to what actual .plt file, when it gets downloaded, etc
2. Give developers some way to crystallize an entire project, 
potentially consisting of multiple planet packages, into a single file 
that can be distributed (i.e., compile your package using 
statically-linked rather than dynamically-linked libraries, as it were)

Is that an accurate list of all the functionality people want out of 
planet that isn't there yet? I ask because I want to start thinking 
about how to make planet serve people's needs better, so I'd like to 
hear more about what people don't have and want. I particularly want to 
hear any actual problems people are constantly getting frustrated by.

-jacob