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'. Sam _________________________ Racket Developers list: http://lists.racket-lang.org/dev
