[racket-dev] PLaneT(2): Single vs multi-collection packages

On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay <eli at barzilay.org> wrote:

> Yesterday, Laurent wrote:
> > On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay <eli at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130603/1227b0be/attachment-0001.html>