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

Jacob Matthews wrote:
> Anton van Straaten wrote: 
>>
> > 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.)

I see a couple of problems with this.

First, if *I* make a choice to change the version of something I'm 
depending on, for whatever reason, I still have the problem I mentioned. 
   Noel gave an example of this in his message "PLaneT and beta releases".

Most commonly, the same version of a particular collection is used 
throughout a given application (not that other options shouldn't be 
supported, though).  It shouldn't be necessary - or at least, it's not 
ideal - to have to touch every source module to change the specific 
version of a collection being depended on.  Relying on the PLaneT 
maintainer to upgrade my packages when I need them upgraded only works 
in some scenarios, and doesn't deal with many situations other than 
simple compatible upgrades.

Second, and a kind of corollary to the above point: 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.

A level of indirection between those X and Y values and what gets loaded 
as a result isn't necessarily a bad thing, *if the developer can control 
it*.  If someone else controls it, its potential to be a source of 
uncertainty and bugs becomes extremely high, because that someone else 
can't possibly anticipate every usage scenario for every collection that 
they're hosting.  The only truly safe decision such a maintainer can 
make is never to change the implementation that corresponds to a 
particular X & Y, no matter how temptingly compatible two versions might 
seem.

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.

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

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.

Anton