<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 9, 2012 at 6:14 AM, Sam Tobin-Hochstadt <span dir="ltr"><<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote:<br>
> On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br>
>><br>
>> 30 minutes ago, Jay McCarthy wrote:<br>
>> > On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br>
>> ><br>
>> > > One other thing that I think is important in a migration path is<br>
>> > > keeping any modification made to the source of the packages that<br>
>> > are<br>
>> > > already installed.<br>
>> ><br>
>> > Yeah -- and IIUC, the difference between the two installations is<br>
>> > where the packages get installed is where the compiled files are, so<br>
>> > the sources are the same. At least I *hope* that that's how it is,<br>
>> > otherwise it's back to the whole planet "cache" things, which IMO<br>
>> > was<br>
>> > a major mistake.<br>
>> ><br>
>> > They are in the same place. However, I thought the whole premise of<br>
>> > this proposed behavior is that the package won't work in the new<br>
>> > version of Racket, so certainly the package system can't be<br>
>> > responsible for doing a merge your local changes and whatever the<br>
>> > updated version of the package needs.<br>
>><br>
>> I'm not following that -- the compiled files and the sources are in<br>
>> the same place? If so then it makes the whole migration thing kind of<br>
>> impossible with local changes, no? (And I wasn't thinking about<br>
>> merging, just reusing the same sources.)<br>
><br>
><br>
> :) Now I'm not following you.<br>
><br>
> If you have a package named P that has a module A/B/C.rkt then on your disk<br>
> is in:<br>
><br>
> ~/.racket/$version/pkgs/P/A/B/C.rkt<br>
><br>
> with its compiled code in:<br>
><br>
> ~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo<br>
><br>
> My idea of "raco pkg migrate" is just to get a list of the packages that you<br>
> have installed and re-install them. I think if we assume that Racket<br>
> versions will break package P then those same problems will prevent you from<br>
> keeping local changes; especially if the package system isn't responsible<br>
> for running merge, which it clearly shouldn't be. (Now, I don't think that's<br>
> a reasonable assumption, i.e. I think version-less should be the default,<br>
> but I've clearly been out-voted.)<br>
<br>
</div></div>First, I still agree with you about version-less being the default.<br>
<br>
Second, I think an upgradeable installation, replacing the `bin` and<br>
`collects` directories, so that migration of packages isn't needed<br>
would work better -- that's more like how those of us who use git<br>
work, and I think we're mostly happy with that.<br>
<br>
But even with `migrate`, I think the behavior *needs* to be be 'copy<br>
the files, call `setup`'. Otherwise it won't work on a system without<br>
the internet, for example. My impression about the reasons for<br>
version-specific packages and 'migrate' are that when upgrading, just<br>
keeping the same code will potentially error, and so users shouldn't<br>
*automatically* keep the same code. But I thought of `migrate` as<br>
'make it seem like those packages were installed for this new<br>
installation'.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Jay</div></div><br clear="all"><div><br></div>-- <br>Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>><br>Assistant Professor / Brigham Young University<br><a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
<br>"The glory of God is Intelligence" - D&C 93<br>
</div>