Modules/getpath.c chases links?

[Fred L. Drake, Jr.]

Edward Jason Riedy writes:
 > Is there a reason why Modules/getpath.c chases links to get the
 > `correct' path?  I'd like to see that removed, but the comments
 > make me think someone had a specific reason for including it.

Jason,
  Without that, automatic detection of the installation directories
becomes massively fragile.  Consider a fairly reasonable installation:

  $prefix == $exec_prefix == /opt/python/1.5.2

symlinks:

  /usr/local/bin/python --> python152
  /usr/local/bin/python152 --> /opt/python/1.5.2/bin/python

  Without the symlink chasing, the standard library won't be found (I
don't think it even needs to be that complex).

 > I use symlink trees to separate out different versions of packages 
 > distributed by different people (here, stock python 1.5.2 and the
 > LLNL-distributed  NumPy).  The symlink chasing breaks this badly
 > by looking into the symlinked directory rather than using the tree
 > of symlinks.

  I'm not sure I follow.  This sounds incredibly difficult to
maintain.  What does it buy you?

 > Simply removing the code protected by HAVE_READLINK makes my life 
 > much nicer.  I'd really like to see it officially removed.  (If you
 > want a full-featured system for finding the installation, check the
 > kpathsea library in the Web2C distribution of TeX.)

  kpathsea is overkill for most things; anything that doesn't have the 
number of critical configuration items that a TeX installation has
doesn't need such a heavy approach.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives