[issue4725] reporting file locations in egg (and other package) files

rocky bernstein report at bugs.python.org
Mon Dec 22 18:56:25 CET 2008


New submission from rocky bernstein <rocky at gnu.org>:

When listing a traceback or showing stack frames or implementing a
debugger (or a tool which wants to track the exact location of the
source code), how is one supposed to detect a file located inside an egg
or some other archive mechanism? 

There are a number of issues, I think. First, I think some sort of
consistent naming convention would be helpful. 

Here's an example of the current situation. I have a file called
tracer.py inside egg
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py
and I get an exception inside of that. The traceback shows this:

   File "build/bdist.linux-i686/egg/tracer.py", line 216, in size

The file information comes from frame.f_code.co_filename and its
relation to a file is a bit nebulous since there is no file either in
the filesystem with that path suffix nor a file in an with that name.
(It's possible there was a file with that suffix at one time during the
build of the egg.)

So possibly this is a bug.

Via the __loader__ key in the tracer module's __dict__ hash (a 
zipimporter object) there is a _files hash which has a key "tracer.py"
with value
"/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py".
This seems to correspond to a file tracer.py in zip file:
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg 

Glomming the two parts together as one entity or one name is a bit weird
and means that things that work on files will have do some parsing to
figure out that this there is a member inside an archive (and egg here). 

PEP 302 has lots of interesting things in it such as a way to get the
file source text, but it doesn't specify uniform file *names* of either
the surrounding package/archive or the member inside that.

So possibly this is an omission or something that should be added.

Finally looking at linecache.py, the function update_cache() has a
routine to do some sort of filename resolution consulting loaders using
the API of PEP 302. Possibly the name resolution part (without reading
file data) might be made callable by itself so that it returns a
package/archive name and a package/archive member name.

----------
messages: 78203
nosy: rocky
severity: normal
status: open
title: reporting file locations in egg (and other package) files
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4725>
_______________________________________


More information about the Python-bugs-list mailing list