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

Here is a patch for a proof of concept (file /collects/pkg/lib.rkt).

The modifications are minimal as I had expected, but obviously I only have
a very narrow view of the package system, so probably something does not
work properly.
In particular, I changed only for the 'dir type, and did not touch the
'link type.
Since the 'github type and others use the 'dir type once the archive is
downloaded, I think it should work as expected for those too.

I've tested on an "old" 5.3.4.10--2013-05-13(96acfb0/a) [3m], but made the
patch with the latest in git, and it still works with the old version.
(I was about to test it with the latest nightly, but its installation
failed, see the mailing list)

To try it, in the collects/pkg directory:
$ patch lib.rkt lib.rkt.patch
$ sudo raco setup -D pkg

Then create a dummy package:
$ cd /tmp
$ mkdir dummy
$ echo '#lang racket\n(displayln "It works!")' > dummy/main.rkt
$ touch dummy/single-collect

The file "single-collect" is here to signal that this package is a
single-collection package (it's not the right way to do it, but it's a
proof of concept).

Install the package:
$ raco pkg install -t dir dummy

(You should see "This is a single-collection package" as the first line of
the log)

Then try it:
$ racket
> (require dummy)
It works!

Or is this patch way too naive for some reason?

Laurent



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

> (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 <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
> >
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130603/e98b4ad1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib.rkt.patch
Type: application/octet-stream
Size: 1098 bytes
Desc: not available
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130603/e98b4ad1/attachment.obj>