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.

Author omnifarious
Recipients
Date 2004-11-26.23:07:45
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2007-08-23 14:27:50adminlinkissue1074015 messages
2007-08-23 14:27:50admincreate