[plt-scheme] End-user instructions for upgrading single PLaneT package

On Mon, May 18, 2009 at 10:15 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> Robby Findler wrote at 05/18/2009 10:52 AM:
>>
>> Well, it is a bit more complex than that, due to the "no automatic
>> upgrades" mantra we adpoted early on in planet. Specifically, there
>> can be multiple versions at once of a given planet package and two
>> requires of the same package can actually be mapped to different
>> versions, depending on how the installation happened. Might be worth
>> having a look at Jacob's Scheme workshop paper on planet.
>>
>> But I do agree that we need a better setup for planet packages whose
>> main purpose is a drscheme tool and to support beginners.
>>
>
> This is a user-initiated upgrade, not an automatic one.
>
> I think that wanting to make it easy for users to selectively upgrade
> packages is a general need, not specific to educational DrScheme tools.
>  (What's more questionable is the existing functionality in PLaneT, which
> effectively upgrades *all* PLaneT packages.)
>
> The only exception I see to wanting make it easy for user to selectively
> upgrade packages is when you have a configuration of specific versions of
> packages that has been integrated and QA'd, such as for a production server.
>  In that case, you'd effectively require exact versions anyway, so that you
> get the exact versions regardless of what PLaneT cache exists on whichever
> machine it is deployed.
>
> That is the exception, not the general mode, which is that people are mixing
> and matching different versions all the time and the PLaneT versioning
> system is designed to support that.
>
> User-initiated selective upgrades should work fine, given that the
> versioning system works, and they fit a typical usage scenario of users
> wanting to upgrade to get new enhancements into their PLaneT cache.

Just to be clear, I essentially agree with everything you've written.
We do need something better and tool support for it. A GUI that helps
the user's control the upgrades would be a great idea. (IF you were to
write one I'd be happy to take it!)

But I think that the planet version setup is a little more complex
than what comes across in your message and it is that complexity that
drove the current design. Specifically, when we designed PLaneT, Jacob
and I spent a lot of time trying to figure out how to avoid the "magic
upgrade" problem.

Here's the issue, in a nutshell. Say that you install planet package
B, which requires A:1.0. You use B and it works well for doing what
you need done. Later on, you install C. It needs package A as well,
but it needs A:1.1. Furthermore, there is some change in A's 1.0 to
A's 1.1 that breaks something about the way B works. When you
installed C, however, you weren't thinking about A -- maybe you didn't
even really realize that A exists. If A were automatically upgrded,
your B-based program would stop working and you'd be quite confused.

Thus, planet aims to make it be true that installing new packages can
never break existing, already installed code. Thus versions of
software packages are not installation specific, but instead are
file-specific. That is, the mapping from the require line to the
planet version that is used depends on where the require appears in
the program and what version that require got the first time it was
executed.

Anyways, I realize that's a bit apologetic and doesn't actually help
you in the slightest, but I hope it at least clarifies why the current
planet setup isn't completely without merit.

Robby