This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: current directory in sys.path handles symlinks badly
Type: Stage: test needed
Components: Interpreter Core Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: ajaksu2, brett.cannon, marko, omnifarious
Priority: normal Keywords:

Created on 2004-11-26 23:07 by omnifarious, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
recreatebug.sh omnifarious, 2004-11-26 23:07 The script to recreate a bug. Should be run in an empty directory you have write permissions to.
recreatebug.sh marko, 2009-06-18 23:54
Messages (4)
msg23339 - (view) Author: Eric M. Hopper (omnifarious) Date: 2004-11-26 23:07
Here is a script to create the bug:
------------
rm -rf joe barney lib
mkdir joe
mkdir barney
echo "import pprint, sys" >joe/joe.py
echo "pprint.pprint(sys.path)" >>joe/joe.py
echo "import barney" >>joe/joe.py
touch barney/barney.py
mkdir lib
cd lib
ln -s ../joe/joe.py ../barney/barney.py .
python2.3 joe.py
------------

The output for this is:

['/home/hopper/tmp/py-bug/joe',
 '/usr/lib/python23.zip',
 '/usr/lib/python2.3',
 '/usr/lib/python2.3/plat-linux2',
 '/usr/lib/python2.3/lib-tk',
 '/usr/lib/python2.3/lib-dynload',
 '/usr/lib/python2.3/site-packages',
 '/usr/lib/python2.3/site-packages/gtk-2.0']
Traceback (most recent call last):
  File "joe.py", line 3, in ?
    import barney
ImportError: No module named barney

The script should be able to run successfully.

What's going wrong is this...
When python loads up 'joe.py' at startup, it looks at
it and notices it's a symlink.  So it adds the
directory for the file the symlink ultimately resolves
to to the path.  This is almost a wise thing to do, but
not quite.

What should happen is that it should look up the
directory the file is in, and if _that's_ a symlink,
put the directory it ultimately resolves to on the path.

We have a deployment system where I work that builds
deployment directories by symlinking things into them.
 This sets it up so sys.path ofen has surprising and
confusing values, depending on what script you run with
the interpreter.
msg81702 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-02-12 01:22
Still happens in trunk.
msg84682 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-03-30 22:18
So the joe directory is put on sys.path instead of lib because joe.py
resolves to joe/joe.py. I think that is correct semantics as you may
symlink that file into your bin directory but the original file has
dependencies in that location. Plus changing it now would break scripts
depending on the current semantics.

Closing as won't fix.
msg89514 - (view) Author: Marko Schuetz (marko) Date: 2009-06-18 23:54
I think this behavior is causing a related problem:

Assume I have directories currentWorkspace and branchRepository.

On branchRepository I have files main.py and module.py. main.py 
imports module.py. In currentWorkspace main.py links to the repository 
version, but module.py has a new version in currentWorkspace. Running 
main.py will not import the module.py from currentWorkspace.

I agree that branchRepository belongs on the search path, but 
currentWorkspace needs to be on the search path also and needs to take 
priority over branchRepository.

The attached file is an edit of the original recreatebug.sh
History
Date User Action Args
2022-04-11 14:56:08adminsetgithub: 41234
2009-06-18 23:54:08markosetfiles: + recreatebug.sh
nosy: + marko
messages: + msg89514

2009-03-30 22:18:52brett.cannonsetstatus: open -> closed
resolution: wont fix
messages: + msg84682
2009-02-12 01:22:10ajaksu2setnosy: + ajaksu2
messages: + msg81702
stage: test needed
2009-02-11 03:04:06ajaksu2setassignee: brett.cannon
components: + Interpreter Core, - None
nosy: + brett.cannon
2004-11-26 23:07:45omnifariouscreate