Bad tracebacks from packages installed using setuptools
Hi there, I'm getting tracebacks like this from a package (pymbolic in this case--available from PyPI) installed using setuptools. 8< ----------------------------------------------------------------------------- File "build/bdist.linux-x86_64/egg/pymbolic/primitives.py", line 150, in __str__ File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 17, in __call__ File "build/bdist.linux-x86_64/egg/pymbolic/mapper/stringifier.py", line 75, in map_product File "build/bdist.linux-x86_64/egg/pymbolic/mapper/stringifier.py", line 75, in <genexpr> File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 58, in rec File "build/bdist.linux-x86_64/egg/pymbolic/mapper/stringifier.py", line 23, in handle_unsupported_expression 8< ----------------------------------------------------------------------------- At least two things are bad here: - Some source files refer to their relative location in the build directory of their *own* package. Unsurprisingly, this is not found when an exception occurs in user code that does not live in the package's base directory. - Whenever a file name is __init__.py, the PIL __init__.py gets picked up instead of the corect file name. (nothing uses PIL in what generated the above) What can I do to fix this? (setuptools 0.6c8 on 2.5) Thanks Andreas
At 12:16 PM 5/12/2008 -0400, Andreas Klöckner wrote:
At least two things are bad here:
- Some source files refer to their relative location in the build directory of their *own* package. Unsurprisingly, this is not found when an exception occurs in user code that does not live in the package's base directory.
- Whenever a file name is __init__.py, the PIL __init__.py gets picked up instead of the corect file name. (nothing uses PIL in what generated the above)
What can I do to fix this? (setuptools 0.6c8 on 2.5)
The first can only be fixed by installing files unzipped; the second I've never seen before and have no idea about.
On Montag 12 Mai 2008, Phillip J. Eby wrote:
At 12:16 PM 5/12/2008 -0400, Andreas Klöckner wrote:
- Some source files refer to their relative location in the build directory of their *own* package. Unsurprisingly, this is not found when an exception occurs in user code that does not live in the package's base directory.
- Whenever a file name is __init__.py, the PIL __init__.py gets picked up instead of the corect file name. (nothing uses PIL in what generated the above)
What can I do to fix this? (setuptools 0.6c8 on 2.5)
The first can only be fixed by installing files unzipped;
I assume that this depends on core Python getting smarter about how it fetches these lines. Are there plans to address this?
the second I've never seen before and have no idea about.
Hmm, ok. I'll try and investigate at some point. Andreas
On May 12, 2008, at 10:16 AM, Andreas Klöckner wrote:
- Some source files refer to their relative location in the build directory of their *own* package. Unsurprisingly, this is not found when an exception occurs in user code that does not live in the package's base directory.
http://allmydata.org/trac/setuptools/ticket/4 # (when considering whether to zip, err on the side of safety rather than performance)
- Whenever a file name is __init__.py, the PIL __init__.py gets picked up instead of the corect file name. (nothing uses PIL in what generated the above)
http://allmydata.org/trac/setuptools/ticket/3 # (setuptools invokes system-wide setuptools instead of local setuptools, possibly due to interference from nevow) Both of these tickets (as all tickets in http://allmydata.org/trac/ setuptools ) ought to be migrated to the new, official setuptools issue tracker at http://bugs.python.org/setuptools/ . Regards, Zooko
participants (3)
-
Andreas Klöckner -
Phillip J. Eby -
zooko