<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 7:36 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"><div id=":1bv" style="overflow:hidden">The simplification of not handling links also seems like a big weakness<br>
to me. I think one of the best things about Jay's design is that I<br>
don't have to change the way I think about a package when moving<br>
between link and non-link modes (which makes it much easier to work<br>
with a GitHub repository, for example). I particularly encourage you to<br>
think about what should happen when a user needs to transition a GitHub<br>
repo from a representing a single-collection package to a<br>
multiple-collection package --- and how that interacts with links as<br>
well as non-link, GitHub-based installations of the package.</div></blockquote></div><br></div><div class="gmail_extra">Actually I use collection links instead of package links for my single-collection packages, which are Github clones. It kind of makes sense. (One more homogeneous possibility would be to add a `raco pkg install --link-single <my-collect/package>` command that is just a synonym for `raco link <my-collect/package>`. Actually I would much prefer to have `raco pkg install --link` work like `raco link` and have an additional `raco pkg install --link-multi` command instead.)<br>
<br></div><div class="gmail_extra">As Greg suggested, the single-collection package would have only one info.rkt file (which is simpler for the user[*]), and would contain both the info for the package and for the collection. As they seem to have mutually-exclusive information, it should be ok. (But one would have to be sure that this will remain the case in the future but I think it should hold. I think it should be ok too, see at the bottom of the email.)<br>
</div><div class="gmail_extra">E.g., dependencies of a single collection fit well in the collection's info.rkt I think (meaning these are the dependencies of the collection).<br></div><div class="gmail_extra"></div>When installing the package with 'dir, the collection gets its own subdir, and the info.rkt file just needs to be copied in the package directory.<br>
<div class="gmail_extra"><br></div><div class="gmail_extra">When changing from a single-collection to a multi-collection package, you'd have to do (I think):<br></div><div class="gmail_extra">- collect-unlink the current package,<br>
</div><div class="gmail_extra">- move the collection to a subdirectory (along with the info.rkt file),<br></div><div class="gmail_extra">- create a info.rkt file in the package root, and move the parts of the collection's info.rkt that are package-specific to this new file,<br>
</div><div class="gmail_extra">- package-link the new package.<br><br></div><div class="gmail_extra">Since I don't expect people (other than the Racket dev) to do that often (or even at all for most of them), I don't see that's a problem (it's not even a big deal).<br>
</div><div class="gmail_extra">When someone wants to do that, it means he already has some good knowledge about collections and packages (since he wants to build a multi-collection package), and thus it should not be a problem either.<br>
<br></div><div class="gmail_extra">You could generalize the principle:<br></div><div class="gmail_extra">- When all you need is a file, just use a file. It should have all the necessary information (i.e., why not have a 'info' submodule? E.g. to deal with dependencies)<br>
</div><div class="gmail_extra">- If you need several files, create a folder, put your files in there, and add a collection-specific file (info.rkt)<br></div><div class="gmail_extra">- if you need several collections (a package), create a new folder, put your collections in there, add a file that is specific to the collection of collections (the package)<br>
</div><div class="gmail_extra">- if you need several packages (a repository?), create a new folder, put your packages in there, etc.<br></div><div class="gmail_extra">- etc.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
The info.rkt files that are closer to the root are more general, and more specific info.rkt files should have precedence in case there is a conflict (like in CSS for example).<br><br></div><div class="gmail_extra">I expect the first two cases to be overwhelmingly dominant, and thus they should be easier to achieve.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Laurent<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">[*] I think a good tool is one that asks for Minimum User Effort, and if the user wants to do something simple, it should be simple to achieve. <br>
</div></div>