[racket-dev] proposal: `data' collection

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?