[racket-dev] Planet 2 Beta Release

On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay <eli at barzilay.org> wrote:
>>
>> 30 minutes ago, Jay McCarthy wrote:
>> > On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay <eli at barzilay.org> wrote:
>> >
>> >     > One other thing that I think is important in a migration path is
>> >     > keeping any modification made to the source of the packages that
>> > are
>> >     > already installed.
>> >
>> >     Yeah -- and IIUC, the difference between the two installations is
>> >     where the packages get installed is where the compiled files are, so
>> >     the sources are the same.  At least I *hope* that that's how it is,
>> >     otherwise it's back to the whole planet "cache" things, which IMO
>> > was
>> >     a major mistake.
>> >
>> > They are in the same place. However, I thought the whole premise of
>> > this proposed behavior is that the package won't work in the new
>> > version of Racket, so certainly the package system can't be
>> > responsible for doing a merge your local changes and whatever the
>> > updated version of the package needs.
>>
>> I'm not following that -- the compiled files and the sources are in
>> the same place?  If so then it makes the whole migration thing kind of
>> impossible with local changes, no?  (And I wasn't thinking about
>> merging, just reusing the same sources.)
>
>
> :) Now I'm not following you.
>
> If you have a package named P that has a module A/B/C.rkt then on your disk
> is in:
>
> ~/.racket/$version/pkgs/P/A/B/C.rkt
>
> with its compiled code in:
>
> ~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo
>
> My idea of "raco pkg migrate" is just to get a list of the packages that you
> have installed and re-install them. I think if we assume that Racket
> versions will break package P then those same problems will prevent you from
> keeping local changes; especially if the package system isn't responsible
> for running merge, which it clearly shouldn't be. (Now, I don't think that's
> a reasonable assumption, i.e. I think version-less should be the default,
> but I've clearly been out-voted.)

First, I still agree with you about version-less being the default.

Second, I think an upgradeable installation, replacing the `bin` and
`collects` directories, so that migration of packages isn't needed
would work better -- that's more like how those of us who use git
work, and I think we're mostly happy with that.

But even with `migrate`, I think the behavior *needs* to be be 'copy
the files, call `setup`'.  Otherwise it won't work on a system without
the internet, for example. My impression about the reasons for
version-specific packages and 'migrate' are that when upgrading, just
keeping the same code will potentially error, and so users shouldn't
*automatically* keep the same code.  But I thought of `migrate` as
'make it seem like those packages were installed for this new
installation'.

Sam