I've pushed the splice-at-file-level change so we can try it out. There are many uses of `collection-path' that should change to `collection-file-path'. Most would be easy to change, but as expected, that's not always the case. For a while, I think file-level splicing will work well only for collections where that's expected, such as the possible "data" collection.
At Fri, 9 Jul 2010 13:10:26 -0600, Matthew Flatt wrote: > 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
