[Distutils] Import error from Trac for Setuptools

[Phillip J. Eby]

At 05:18 PM 7/20/2006 -0400, chtaylo3 wrote:
>Hello all,
>
>I'm running Tracd as a normal user.  When I try and access the tracd server
>from a remote computer, I get the error mentioned at the end of this 
>post.  It
>looks like a new Workset object is being created with no parameters.  So
>because entries==NONE then entires=sys.path in the constructor.  It then 
>calls
>add_entry  which calls find_distributions().  Somehow (I'm not sure how), we
>get into find_on_path where os.listdir() is called, and this is where it 
>blows
>up.
>
> >From the errors given, it looks like it's trying to do a listdir on the
>contents of /usr/bin and it get's into permissions trouble.  However, 
>/usr/bin
>is not part of $PYTHONPATH and therefore should not be in the results 
>returned
>from sys.path.
>
>When I run python from the shell, and import sys and then do a sys.path I get
>the following output:
>
>['', '/usr/lib/python2.4/site-packages/setuptools-0.6b4-py2.4.egg',
>'/usr/lib/python2.4', '/usr/local/lib/svn-python',
>'/usr/local/lib/svn-python/svn', '/usr/local/lib/svn-python/libsvn',
>'/usr/lib/python24.zip', '/usr/lib/python2.4/plat-linux2',
>'/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload',
>'/usr/lib/python2.4/site-packages']
>
>So I have two questions
>
>1) From a simple import command, how are we getting into find_on_path when
>it's find_distributions that is being called?

find_distributions returns a dynamically-chosen generator, based on whether 
the path is a directory or a zipfile (or other type of importer).  In this 
case, it's find_on_path, which looks in a directory to see what projects 
are present.


>2) What could have interjected the /usr/bin dir into the $PYTHONPATH variable
>that reuslts in us calling listidr on /usr/bin?

It's not being injected in $PYTHONPATH.  What's presumably happening is 
that the script that starts trac is in /usr/bin.  Python always includes 
the startup script's directory in sys.path.

Thus, a quick way to work around this would be for you to copy the script 
from /usr/bin to some other directory, and run that copy instead of the one 
in /usr/bin.  That way, it won't scan a directory you don't have 
permissions to read.

Meanwhile, I'll make sure that the problem (of handling directory 
permission errors gracefully) is addressed in a future release of 
setuptools.  Thanks for the very detailed and well-investigated problem report!