<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</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>Yesterday, Laurent wrote:<br> > On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay <<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>> wrote:<br> ><br> > To clarify, because of reasons that I won't go into on the list,<br> > the actual chances of me getting this implemented (and of such a<br> > change being accepted) are pretty much in the area of "slim to<br> > none". <br> ><br> > That's a bummer. At first sight I'd have thought that it would have<br> > just been a matter of creating a directory with the same name as the<br> > package, and then decompressing the package into that directory.<br> <br> </div>At the lower level, packages use links, and "raco link"'s default mode<br> of work is at the collection level. There is obviously a need for<br> packages that correspond to collection roots, but I wanted to see the<br> default being the same as the raco-link default (which fits most uses<br> that don't come out of the current main tree).<br></blockquote><div><br></div><div>Not sure I was clear, or I don't exactly understand what you mean.<br></div><div>And maybe I'm missing some important point here.<br> </div><div><br></div><div>But the more I think about it, the less I see why this <br>double-directory thing should be the default behavior of the new package<br>system (I can understand why it's useful for plt packages though). <br> </div><div>Even Carl's "mischief" package doesn't make use of collections like <br>that.<br></div><div>Jen's "this-and-that" does, though, but then every collection of his <br> package must have a name that is different from any existing collection.<br></div><div>(And actually I think that's a bad idea, and that he should split his <br>package into several single-collection packages −unless they are <br> tightly related− because I don't want to install all his collections if I want <br>to only try one of them, unless there is a way to install only one <br></div><div>collection of an existing package?)<br></div><div><br> </div><div>For example, my personal racket project tree is arranged somewhat like <br>that:<br></div><div><span style="font-family:courier new,monospace">racket<br> ├── project-B<br>│ └── main.rkt<br>├── project-A<br>│ └── main.rkt<br>├── not-yet(?)a-project-C<br>├── my-collects<br>│ ├── slideshow<br>│ ├── scribble<br>│ ├── racket<br>│ └── data<br>└── misc<br> ├── try-this.rkt<br> └── try-that.rkt</span><br><br></div><div>project-A and project-B are git clones.<br></div><div>my-collects contains all my extensions to racket's collections,<br></div><div>plus some more generally useful collections.<br> </div><div> <br>For my personal use, I just do:<br> raco link project-A project-B my-collects<br>and all is fine.<br></div><div></div><div>I tend to believe it's a quite common tree for racket users.<br> <br></div><div>In "my-collects", I have names that would collide with racket's collections, <br>so instead of having:<br></div><div>(require orseau/racket/slideshow)<br></div><div>as in the former package system, I would now have<br> (require some-funny-name/slideshow)<br></div><div>after renaming my-collects to some-funny-name to make sure it does not <br>collide with anything else.<br></div><div><br></div><div>... and since I don't want to invent a funny name for each extension of a <br> racket collection I do, I prefer to put them all in a single package and <br></div><div>collection.<br></div><div> <br></div><div>Now if I were to follow the new package system, I'd need to change my <br>tree to:<br><span style="font-family:courier new,monospace">racket<br>├── misc<br>│ ├── try-that.rkt<br>│ └── try-this.rkt<br> ├── </span><span style="font-family:courier new,monospace">some-funny-name</span></div><div><span style="font-family:courier new,monospace"> │ └── some-funny-name<br></span></div><div><span style="font-family:courier new,monospace">│ ├── data<br>│ ├── racket<br>│ ├── scribble<br>│ └── slideshow<br>├── not-yet(?)a-project-D<br>├── project-A<br> │ └── project-A<br>│ └── main.rkt<br>└── project-B<br> └── project-B<br> └── main.rkt</span><br><br></div><div>which is a mess. And I would also need to change my git repos to<br></div><div>match that structure, which looks awkward.<br></div><div>/But/ I don't care if the tree of the packages I *install* look like that.<br> <br></div><div>So what I would like is to keep my tree like the first one, but the <br> package system can still install like the second one.<br><br></div><div>My proposal was that for single-collection packages, I could keep<br></div><div>my tree like the first one, my git clones like project-A/main.rkt, and<br> </div><div>tell the package manager (probably in the info.rkt file) that it is a<br>single-collection package so that when it installs it in the<br>installed-package-directory-that-I-will-not-look-into it generates a tree<br> like the second one.<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"> <div> </div>Well, the reason I think that plain collection packages are important<br> is it will simplify dealing with packages, and lower the investment<br> threshold that you need to publish a package. Along the same line,<br> there should also be a way to put out just a single file (or very few)<br> as a first step where I make some code public but with absolutely<br> minimum effort on the publisher's side. See for example the<br> "Processing" thread, where Sean said that people who do these kind of<br> thing "don't even know what source control is, let alone packages" --<br> so the existence of such a crowd is a perfect reason for a single-file<br> thing being another important point on the code distribution spectrum.<br></blockquote><div><br></div><div>I entirely agree with that, and I think it is of utmost importance for a <br>programming language (and system) to make sure that its users can <br> </div><div>easily share code. Probably all of you agree with that, but I want to <br>emphasize that it's really important to put as much effort as required<br>into that.<br><br></div><div>Don't get me wrong, I really like the steps forward taken with the new<br> direction of the package system, but right now there's a psychological<br>wall that prevents me from publishing more v2 packages.<br></div></div><br></div><div class="gmail_extra">Laurent<br></div><div class="gmail_extra"> <br></div></div>