At Tue, 4 Jun 2013 07:41:53 -0400, Eli Barzilay wrote: > Yesterday, Jay McCarthy wrote: > > 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. > > This shouldn't be a problem
At Tue, 4 Jun 2013 10:32:12 +0200, Laurent wrote: > As Greg suggested, the single-collection package would have only one > info.rkt file (which is simpler for the user[*]), and would contain both > the info for the package and for the collection. I agree with both of you. My intent in echoing Jay's comment about "info.rkt" was to point out areas that need attention to fill out the patch --- not to suggest that it isn't possible to make things work. More generally, I hope I haven't come across as being firmly opposed to the idea of single-collection packages. I intended to come across as being opposed to implementing the idea myself. :) But it seems that I haven't convinced anyone to take on the implementation task (understandably), and I've arrived back to a point where I want single-collection packages (in the ongoing collection-splitting experiment). So, the enclosed patch is a suggestion on how to have single-collection packages. With the patch, a single-collection package must have an "info.rkt" file containing a definition of `single-collection' as a string, and the string is used as the package's collection name. That is, you don't have to know from the outside what kind of package you're installing; it's up to the package author to choose single-collection mode or multi-collection mode within the package's implementation. A package in either mode can be upgraded to the other mode. If you install a package with `--link' and you want to change modes, the only available "upgrade" process (at the moment) is to remove and re-install the package. Some other the details: * A package's mode is recorded in the installed-package table. Otherwise, a linked package could switch modes just because the package directory's content changes, which would be difficult to keep in sync with the low-level table of links. * Both modes are handled in-place instead of trying to reshape one mode's directory structure to the other. * In a single-collection package, "info.rkt" doubles as the package's "info.rkt" and the collection's "info.rkt". * ".plt"-format files cannot encode single-collection packages. It's a deprecated format, anyway. I experimented with various ways of distinguishing single-collection packages from multi-collection packages. An "info.rkt" definition seems best among the things I tried, at least. (A discarded experiment was to treat a directory a single-collection package when it has any ".rkt" file other than "info.rkt".) As Jay pointed out to me, putting the collection name in the "info.rkt" file --- instead of using the package name as the collection name --- makes the package content work the same even when the package is renamed. Otherwise, you have to know whether the package is single-collection or multi-collection to know whether changing the package's name changes its content. It's debatable whether single-collection or multi-collection would be a better default, but I favor multi-collection mode. We can try different ways of distinguishing single-collection package from multi-collection packages by changing the implementation of `pkg-single-collection', as long as we stick to the distinction being inside the package instead of outside.
0001-raco-pkg-support-single-collection-packages.patch
Description: Binary data
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
