Bug? zimpimporter putting in a misleading co_filename?
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?
participants (2)
-
Rocky Bernstein
-
zooko