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

Oh, and test cases would go here:

https://github.com/plt/racket/blob/master/collects/tests/pkg/tests-create.rkt

and

https://github.com/plt/racket/blob/master/collects/tests/pkg/tests-install.rkt

On Mon, Jun 3, 2013 at 10:44 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> 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



-- 
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