<div dir="ltr">Great! Thank you very much.<br><div><div class="gmail_extra"><br><div class="gmail_extra">On Wed, Jun 5, 2013 at 11:04 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote: <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
More generally, I hope I haven't come across as being firmly opposed to<br>
the idea of single-collection packages. I intended to come across as<br>
being opposed to implementing the idea myself. :)<br></blockquote><div><br></div><div>I wanted to give it a stab, but didn't have much time. Plus you did it way<br>better than I could have done anyway.<br></div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Some other the details:<br>
<br>
* A package's mode is recorded in the installed-package table.<br>
Otherwise, a linked package could switch modes just because the<br>
package directory's content changes, which would be difficult to<br>
keep in sync with the low-level table of links.<br></blockquote><div><br></div><div>Does it handle the case where user A installs B's single-collection package,<br></div><div>and at some point B changes its package to a multi-collection package,<br>
</div><div>triggering the updating of A's installation?<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As Jay pointed out to me, putting the collection name in the "info.rkt"<br>
file --- instead of using the package name as the collection name ---<br>
makes the package content work the same even when the package is<br>
renamed. Otherwise, you have to know whether the package is<br>
single-collection or multi-collection to know whether changing the<br>
package's name changes its content.<br>
<br>
It's debatable whether single-collection or multi-collection would be a<br>
better default, but I favor multi-collection mode.<br></blockquote><div><br></div><div>What I'd like is to have single-collection being the default so that the<br>average Joe can even not care about including a info.rkt file, and<br>
expect the collection's name to be just the directory's name. Less burden<br>on the user -> more packages.<br></div><div>I believe most users will not even (try to) understand the concept of multi-<br>collection packages. To them a package is just a bunch of source files<br>
</div><div>and that's all.<br><br><div class="gmail_extra">Then to create a simple package, Joe only has to create a directory,<br></div><div class="gmail_extra">put his my-file.rkt in it, and he's done!<br></div>
</div><div><br></div><div>If at some point Joe thinks about having a different name for his package<br></div><div>and for his collection, it should be intuitive to him that he should say so <br>
somewhere (i.e. in the info.rkt file).<br><br></div>So here is a demo patch attached to precise what I mean (without test, <br>would have taken me way too much time). Because it considers that <br>single-collections are the default, it is backward incompatible.<br>
</div><div class="gmail_extra"><div class="gmail_extra">If info.rkt exists, it looks for 'multi-collection, and otherwise looks for the<br></div><div class="gmail_extra">'collection-name string.<br></div><div class="gmail_extra">
If info.rkt does not exist, it creates it and gives the 'collection-name<br></div></div><div class="gmail_extra">the name of the package by default.<br>(This of course fails if the directory is read-only, but since it's just a <br>
useful default it should not be a problem.<br></div><div class="gmail_extra">This should at least work for all downloaded archives.)<br></div><div class="gmail_extra"></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Laurent<br></div></div></div>