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

From: Danny Yoo (dyoo at hkn.eecs.berkeley.edu)
Date: Sat Jun 17 14:43:33 EDT 2006

Hi everyone,

I'm hitting a Unix-y problem that I'm not quite sure how to solve yet. It 
involving the module system and symbolic links.  I'm still a bit confused, 
so let me set up the scenario and perhaps someone can set me straight. 
My apologies in advance for the verbosity:


On a server I don't control, my home directory lives physically in 
'/home/dyoo', but the system administrators have symbolically linked '/u/' 
to '/home'.  It's the subtle difference between:

##############################
metcalfe ~ $ pwd
/u/dyoo
metcalfe ~ $ 
metcalfe ~ $ 
metcalfe ~ $ /bin/pwd
/home/dyoo
##############################


This is relevant to mzscheme because this means that module files don't 
necessarily have a unique path anymore; I can get inadvertant module 
invocation if a require accidently uses both paths.  And unfortunately, 
this is happening to me because my collects directory is rooted under the 
symlink, but current-directory isn't:

################################################
> (current-library-collection-paths)
(#<path:/u/dyoo/.plt-scheme/349.100/collects> 
#<path:/pro/plt/plt/Linux/nightly/plt/collects>)
> (current-directory)
#<path:/home/dyoo>
################################################

(I also symlink individual projects from my personal work directory into 
/home/dyoo/.plt-scheme/349.100/collects)


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, which uses '/home/dyoo' as my base, vs 
using a '(lib ...)' form later on, which uses '/u/dyoo'.  This seems like 
such a trivially silly problem, but it's been giving me no end of grief. 
I'm doing module injection with namespace-attach-module, where having a 
single canonical path for a module is critical, and the code is so fragile 
depending on how I've deployed the project.


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?


Best of wishes!


Posted on the users mailing list.