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

You would need to update the metadata calculation, such as

https://github.com/plt/racket/blob/master/collects/pkg/lib.rkt#L154

and you should deal with the non-proof of concept method of specifying
it in, for instance, the info file, which is now package info AND
collect info.

Finally, you have to deal with how to say what the name of the
collection is, because it can't be derived only from the source,
because we want to be able to have

package-from-20130203.tgz

have collections other than "package-from-20130203" in it.

Jay


On Mon, Jun 3, 2013 at 10:37 AM, Laurent <laurent.orseau at gmail.com> wrote:
> 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!
>
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93