[plt-scheme] module name resolution, symlinks, and path normalization

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Jun 17 16:50:02 EDT 2006

At Sat, 17 Jun 2006 11:43:33 -0700 (PDT), Danny Yoo wrote:
> The scenario I run into in my own project involves cases where, in 
> dynamically generated code, I'm constructing module paths using 
> this-expression-source-directory

I worry about `this-expression-source-directory', and you've provided a
good example of the problem.

To locate something in a collection, use `collection-path' instead. If
you have some code that may or may not be installed in a collection,
then I'm afraid I don't have a good answer for you.

> The root of the problem is that the standard module name resolver isn't 
> doing a path-normalization to strip off symlink directories a-la the 
> normalize-path function in (lib "file.ss").
> 
> The path canonicalization that the standard module name resolver does now 
> is described in Section 5.4.1 in the Reference manual as "... the 
> expanded, simplified, case-normalized, and de-suffixed path of the file 
> designated by the module path."  If it's doing all that, would it be 
> reasonable to ask for symlink normalization as well?

Path normalization is losing game. A filesystem can be mounted at
multiple roots, case sensitivity actually depends on the filesystem and
not the OS (except for Windows), files can be hard-linked instead of
soft-linked, and so on. That's why the documentation for
`normalize-path' warns that comparison of normalized results is not
reliable.

Expansion, simplification, case-normalization, and de-suffixing operate
on the path, not its connection to the filesystem. Symlink
normalization depends on the filesystem, so that's why it's not
included.

(Actually, I see that `simplify-path' is used with the default #t
argument as the second argument, which means it may consult the
filesystem. I'll have to fix that.)

In other words, the intended connection between module names and files
is not that each file corresponds to a module, but that each file
*path* corresponds to a module. The difference is subtle --- and having
a module<->file mapping might be nicer, but I don't think it's
tractable in general.

Matthew



Posted on the users mailing list.