[racket-dev] proposal: `data' collection

At Sat, 10 Jul 2010 01:48:09 -0400, Eli Barzilay wrote:
> On Jul  9, 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.
> 
> Was there an issue of efficiency?  

I don't think so.

> Also, I think that there was a
> potential issue with, for example, "collects/foo/bar.rkt" having:
> 
>   (require foo/blah)
>   (require "blah.rkt")
> 
> not have the same meaning, since the first would search for the file
> in all roots, and the second is always in the same directory. So
> assuming those would be different, there should be a scan on all
> requires in the tree, making sure that the appropriate style is used.

Using "blah.rkt" wouldn't always mean the "blah.rkt" in the same
directory, due to the occasional need for module-path collapsing (as
opposed to module-path resolution). That is, neither style of `require'
would avoid the possibility that "blah.rkt" comes from a different
directory or that there will be a mess if it exists in multiple places.

On points like this, I came to the conclusion that users can just break
things with bad collection configurations. Similar bad things can
happen with "info.rkt" files. Maybe `raco setup' should perform a
sanity check, but I don't think we can rule out this kind of confusion
by design within our current constraints.