<div dir="ltr"><div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</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>On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt <<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>> wrote:<br> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>> wrote:<br> >><br> >><br> >>> What I'd like is to have single-collection being the default [...]<br> >>><br> >>> So here is a demo patch attached to precise what I mean (without<br> >>> test, would have taken me way too much time). Because it considers<br> >>> that single-collections are the default, it is backward incompatible.<br> >>> If info.rkt exists, it looks for 'multi-collection, and otherwise<br> >>> looks for the 'collection-name string.<br> >><br> >> I could go along with this, as long as (most?) everyone agrees, and as<br> >> long as package authors are willing to update existing packages.<br> ><br> > I am *very* strongly in favor of this -- I'd rather have<br> > single-collection packages than multi-collection packages, if forced<br> > to choose. I'm very glad that you and Laurent have done the work here.<br> <br> </div>The main problem with this is that it brings in internal linking where<br> code directly refers to other packages (implementations) and not<br> modules (interfaces) as the default. This means we will see code like<br> (require jays-awesome-data-structure) rather than (require<br> data/awesome). I think this is bad because it makes it harder to deal<br> with forking, maintainers abandoning their code, splitting packages<br> into packages that just depend on 'jays-awesome-data-structure, rather<br> than implementing it internally, etc. Obviously you can still deal<br> with those things, but if the path of evolution we imagine starts off<br> with single-package-with-package/collection-name-shared, then most<br> packaged collections will have a package as their name.<br></blockquote></div></div><br></div><div>Ok, I see your point.<br></div><div>Let me try to make a use case here:<br></div><div>User A writes package P on Github at A/P.<br> </div><div>A creates a PLaneT package also named P.<br></div><div>User B forks P to B/P.<br></div><div>Since the package name P is already taken, you expect B to name his <br>package B-P.<br></div><div>(But I think you make this point sufficiently clear in the docs that this<br> </div><div>should be very seldom.)<br></div><div><br></div>So on installation, you have a collection name B-P, which is bad, <br></div><div>because you cannot replace A's P directly by B's P, simply by <br>uninstalling A's and installing B's.<br> </div><div><br></div><div>Now, the thing is you'd like B's collection to be name P also, right?<br></div><div>(which means only one could be installed at the same time, otherwise we<br>get back to the same problem, whatever the option we choose.)<br> <br></div><div>Now if we really want to have P as the default collection name for B's P,<br>we could also probably use B's Github repo name. Is it retrievable from<br>the downloaded package?<br></div><div>We would then use this if available, or the package/directory name <br> otherwise (I guess non-repo installations will be rare anyway).<br><br></div>But then people would still write<br><div>$ raco pkg install <jay-awesome-package><br></div><div>but would then need to write<br></div><div> (require awesome)<br><br></div><div>which is, in most cases, quite counter-intuitive: you'd need to state it<br>clearly in the docs of the package, but you would still have "dyslexic" users<br></div><div>asking why it doesn't work (like I have with you, btw, with slideshow-latex).<br> And this will probably occur much more often than the case above, <br></div><div>because you have many more users of packages than developers, and the <br>default should be intuitive for the largest part.<br></div><div> <br> Laurent<br></div><div><br></div><br></div>