At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote: > Back to `data', the problem is that you cannot have two toplevel > `data' collections -- which means that you cannot have separate > distributions of `data/foo' and `data/bar' since they must both appear > in your plt installation or in your user directory -- not in both.
The more I think about it, the more I'm convinced that it's ok to splice collections at the file level instead of the directory level: * Splicing at the file level doesn't create any issues for resolving module names: There's already a search path to find the directory for a collection, and the filename is known at that point, so the filename could be used as part of the search. * The `collection-path' function would have to be deprecated, and we'd add a `collection-file-path' function that splices at the file level. Most uses of `collection-path' could be easily replaced with `collection-file-path'. Some other uses of `collection-path' don't particularly need splicing (e.g., locating a file used by a test suite). A Planet package (or some other code outside the main development repository) might use `collection-path' in a way that would break if a collection is spliced at the file level. If the package is useful enough, I imagine there will be plenty of time to fix it before file-level splicing becomes common. Does anyone see a problem that I've overlooked? _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
