[racket] raco exe error help

At Sun, 8 Sep 2013 20:39:34 -0400, Joe Gibbs Politz wrote:
> I got the following error from raco exe, and could use some pointers
> in turning it into something actionable.  I think I just don't have a
> very good mental model of what raco exe is trying to do.  Here's the
> output:
> 
> $ raco exe -o binary <path>/main.rkt
>
> find-module: module referenced both as a library and through a path:
> <path-to-repo>/lib/whalesong/whalesong/lang/js/js.rkt

Does <path> itself correspond to a collection, or is it outside all
collections?

> My best guess is that this is complaining because there are both
> 
> (require "<stuff>/whalesong/lang/js/js.rkt")
> 
> and
> 
> (require whalesong/lang/js/js)
> 
> and even
> 
> #lang s-exp whalesong/lang/js/js
> 
> in the codebase.  I'm using raco link to manage several collections,
> including this one (whalesong), if that helps.  I didn't write all the
> code that I'm dealing with, so I'm a tad hesitant to dive into
> renaming things without knowing it's the right approach.

Yes, the one with "<stuff>" looks like a problem. Relative-path
references are fine, as long as they don't stray across the boundary
between a top-level collection and its parent directory.

If the <path> provided to `raco exe` is in a collection, that could
cause problems in a similar way.

> Is this assumption correct?  Will finding places where both of these
> require styles appear and making them consistent (path vs library
> name) help, or is that the wrong thing to do?

Yes, I think that would solve the problem.

> Is there any way to avoid doing that?
> 
> What's the underlying problem that this error is avoiding so I can
> understand what to avoid in the future?

As `raco exe` gathers up modules, it has to make everything referenced
on the current filesystem relative, so that the set of modules can be
moved to a different filesystem.

For modules referenced through a collection path, that's easy, because
the references are already relative to the filesystem.

For modules references through a filesystem path, then `raco exe` has
to do more work to manage relative references to *other* modules from
the module that is referenced by a filesystem path. If a module was
first referenced through a collection path, then that extra work wasn't
done, and it's tricky to go back, so `raco exe` panics if a new
filesystem-path reference suddenly demands that extra work. To be on
the safe side, `raco exe' also panics if a new collection reference
doesn't need the work that was already done for a filesystem reference,
because the order in which references were explored is more or less
arbitrary.

Probably, `raco exe` could panic less and handle different reference
styles more gracefully (maybe by justing doing the "extra" work every
time). But I think referencing the same module in different ways ---
filesystem versus collection --- creates trouble in other corners, and
it's best to avoid it if possible.