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.mccar...@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.ors...@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 <e...@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 <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! >> >> > > > > -- > Jay McCarthy <j...@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 <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
