site.py can break the location of the python library

[mwm]

BPO	1514734
Nosy	@brettcannon

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-04-02.02:46:36.473>
created_at = <Date 2006-06-29.22:32:41.000>
labels = ['library']
title = 'site.py can break the location of the python library'
updated_at = <Date 2009-04-02.02:46:36.471>
user = 'https://bugs.python.org/mwm'

bugs.python.org fields:

activity = <Date 2009-04-02.02:46:36.471>
actor = 'brett.cannon'
assignee = 'none'
closed = True
closed_date = <Date 2009-04-02.02:46:36.473>
closer = 'brett.cannon'
components = ['Library (Lib)']
creation = <Date 2006-06-29.22:32:41.000>
creator = 'mwm'
dependencies = []
files = []
hgrepos = []
issue_num = 1514734
keywords = []
message_count = 2.0
messages = ['60933', '85143']
nosy_count = 2.0
nosy_names = ['brett.cannon', 'mwm']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1514734'
versions = []

[mwm]

Given a sufficiently bizarre(*) set of symlinks on a posix system,
site.py will change the directories in sys.path in such a way that
they will no longer refer to valid directories. In the
following. os.path refers to the posixpath file.

The root of the problem is that site.makepath invokes os.path.abspath
on it's paths, which calls os.path.normpath. os.path.normpath assumes
that changing "foo/bar/../baz" to "foo/baz". This isn't true if bar is
a symlink to somewhere where ../baz exists, but foo/baz doesn't.

The simple fix is to make site.py call os.path.realpath on the path
before calling os.path.abspath. This may not be the best fix. Possibly
os.path.abspath should call realpath instead of normpath. Maybe
normpath should check for symlinks and deal with them, effectively
making it an alias for realpath. However, those both change the
behavior of library functions, which may not be desirable.

Here's a patch for site.py that fixes the problem:

--- site.py	Thu Jun 29 18:14:08 2006
+++ site-fixed.py	Thu Jun 29 18:13:57 2006
@@ -63,7 +63,7 @@
 
 
 def makepath(*paths):
-    dir = os.path.abspath(os.path.join(*paths))
+    dir = os.path.abspath(os.path.realpath(os.path.join(*paths)))
     return dir, os.path.normcase(dir)
 
 def abs__file__():

*) Python is invoked as /cm/tools/bin/python. That's a symlink to
../../paks/Python-2.4.3/bin/python, and the library is in
../../paks/Python-2.4.3/lib. /cm/tools/bin is a symlink to
/cm/tools/apps/bin. /cm/tools is a symlink to
/opt/local/cmtools. Changing that relative symlink to an absolute one
fixes the problem, but violates installation guidelines. Trying to
recreate this without all three symlnks in place inevitably fails to
reproduce the problem. And no, I didn't create this. I just diagnosed
it.

[brettcannon]

The semantics of the functions in os cannot change. And I prefer keeping
it as-is since I wouldn't want to change the symlinks on a relative path.