On Sun, Dec 9, 2012 at 6:14 AM, Sam Tobin-Hochstadt <[email protected]>wrote:
> On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy <[email protected]> > wrote: > > On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay <[email protected]> wrote: > >> > >> 30 minutes ago, Jay McCarthy wrote: > >> > On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay <[email protected]> > 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 <[email protected]> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
