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