[Distutils] Bug? zimpimporter putting in a misleading co_filename?

[Rocky Bernstein]

I recently cut over to using distutils to distribute open-source software.
distutils decided to create an zipimporter egg. (Well, I'm sure it did what
it did for good reason, I just am not all that aware of what I did to cause
it too choose that.) When I inspect functions in that egg they seem to have
a path that doesn't really exist. Is there something I did to create this
improperly or perhaps this just they things are?

For concreteness, select one of the eggs at
http://code.google.com/p/pytracer and install one of these.

I did this on GNU/Linux and Python 2.5 and I look at the co_filename of one
of the methods:


>>> import tracer
>>> tracer.__dict__['size'].func_code.co_filename
'build/bdist.linux-i686/egg/tracer.py'

But there is no file called "build/bdist.linux-686/egg/tracer.py" in the
filesystem. Instead there is a member "tracer.py" inside
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg'. Is there something
I could to do cause this to happen?

Related is the question is how one can determine the file location of an egg
and the member for a given import. It looks to me that there is no standard
way defined to do this across loaders that work with some sort of single
archive like a single zipped egg.

Is this correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081222/96251eda/attachment.htm>