<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">&lt;<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>&gt;</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 &lt;<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>&gt; wrote:<br>



&gt; On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt &lt;<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; What I&#39;d like is to have single-collection being the default [...]<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; So here is a demo patch attached to precise what I mean (without<br>
&gt;&gt;&gt; test, would have taken me way too much time). Because it considers<br>
&gt;&gt;&gt; that single-collections are the default, it is backward incompatible.<br>
&gt;&gt;&gt; If info.rkt exists, it looks for &#39;multi-collection, and otherwise<br>
&gt;&gt;&gt; looks for the &#39;collection-name string.<br>
&gt;&gt;<br>
&gt;&gt; I could go along with this, as long as (most?) everyone agrees, and as<br>
&gt;&gt; long as package authors are willing to update existing packages.<br>
&gt;<br>
&gt; I am *very* strongly in favor of this -- I&#39;d rather have<br>
&gt; single-collection packages than multi-collection packages, if forced<br>
&gt; to choose. I&#39;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 &#39;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&#39;s P directly by B&#39;s P, simply by <br>uninstalling A&#39;s and installing B&#39;s.<br>

</div><div><br></div><div>Now, the thing is you&#39;d like B&#39;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&#39;s P,<br>we could also probably use  B&#39;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 &lt;jay-awesome-package&gt;<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&#39;d need to state it<br>clearly in the docs of the package, but you would still have &quot;dyslexic&quot; users<br></div><div>asking why it doesn&#39;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>