Modules/getpath.c chases links?
Fred L. Drake, Jr.
fdrake at acm.org
Mon Nov 29 23:27:36 CET 1999
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.
Without that, automatic detection of the installation directories
becomes massively fragile. Consider a fairly reasonable installation:
$prefix == $exec_prefix == /opt/python/1.5.2
/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 L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
More information about the Python-list