[plt-scheme] How best to use PLaneT?

On Fri, Oct 10, 2008 at 5:50 AM, Matt Jadud <jadudm at gmail.com> wrote:
> Hi everyone,
>
> I generally find coding against PLaneT to be a frustrating experience.
> This is probably due to the way I use it. For this reason, it becomes
> a question of practice.
>
> Question: Should I always code against a specific library version?
>
> I find that if I code against (say) "instaservlet", I have to hope
> that the library maintainers do major revisions when things change
> substantially. I choose this example because, in late August, I wrote
> a script using this library. Since then, PLT Scheme went from 4.0.3 to
> 4.1.x. Instaservlet went from (1 3) to (1 7). Not long ago, while my
> server was live and running, it started throwing errors: instaservlet
> was failing in a live, running app. So, I blew away my cache and
> updated; this now is producing a stream of errors regarding scribble
> and other parts of the system. Obviously, I cannot use the most recent
> PLaneT packages on 4.0.3, because many of them have been updated for
> 4.1.
>
> In short, 4.0.3 is too old to interact with PLaneT at this point. At
> least, that seems to be the case with respect to some libraries.
>
> My solution seems to be to write my code using very explicit versions
> on PLaneT repository objects.
>
> (require (planet "instaservlet.ss" ("untyped" "instaservlet.plt" 1 (= 3))))
>
> was the require statement I should have used. This prevents the
> library from moving underneath me, and means that if the library
> maintainer does not increment their library version with the language
> version (eg. version (1 6) should perhaps have become (2 0) to reflect
> the change from compatibility with PLT 4.0 to 4.1).

I don't understand --- using that require line would've just meant
you'd need to edit the code to fix the problem. Without it, blowing
away cache _could_ have worked, and you can also march through all the
versions of instaservlet from 1.4 to 1.7 to see if any of them solve
the problem. In the specific case you're describing I don't see the
advantage of changing the require line in the way you suggest.

More generally, major-version increments are supposed to reflect
interface changes, not PLT version compatibility changes. In this case
the instaservlet library should've used the required-core-version
facility to indicate that the newer version only supports v4.1; in
fact they can still do that by adjusting its meta-information through
the planet web page. (Though planet is not as smart as it could be on
this front, for instance if package A depends on package B which has
no versions that support v4.0, planet could conclude that package A
doesn't support v4.0 either. It does not do so at present.)

> So, that's the long story, and I believe the lesson I learned (or
> should have known) was "code against specific library versions."
> Should I have taken anything else away?

This is always a trade-off. Whenever you allow multiple versions to
satisfy the same requirement, there's the possibility that one of them
will break something that the others don't. In the case of a program
you're going to be running on your own web server, I actually wouldn't
lock in a specific version in the code; I'd prefer using the
commandline tool to install the particular version I wanted instead.
It gets trickier when you're distributing code to others --- on the
one hand, a new release of a third-party planet package might
introduce a bug (which argues for locking in a particular version),
but on the other hand it might fix one (which argues against locking
in a particular version).

As Robby says, judgment calls like these don't really have anything to
do with planet, they're just a fact of using other peoples' code. I
don't know of any general 'best' policy to apply in these situations.

-jacob