[racket-dev] Planet 2 Beta Release

On Sun, Dec 9, 2012 at 6:14 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:

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


I don't see any difference between what you're proposing and version-less
being default where you type "raco setup" (or something does it for you)
after install. I think that Matthew believes that this won't work because a
user may need to get new source code for a package when the Racket version
changes, but maybe I've misunderstood his worry.

Jay


-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121209/81cc2f61/attachment.html>