[Distutils] PATCH: setuptools-0.4a3 resource loading from egg problem
Ryan Tomayko
rtomayko at gmail.com
Tue Jun 14 15:43:41 CEST 2005
On Jun 14, 2005, at 8:47 AM, Phillip J. Eby wrote:
> At 08:17 AM 6/14/2005 -0400, Ryan Tomayko wrote:
>> Here's a test egg that illustrates the problem:
>>
>> <http://lesscode.org/eggs/somepackage-1.0-py2.4.egg>
>>
>> Install that and then run the included "somescript.py". You should
>> see the traceback above.
>>
>
> I don't; it works fine on my (Windows) PC, assuming all it does is
> spit out a filename.
Oops. Sorry, that test is bad. The problem only seems to manifest
itself when you're trying to use resource_filename on a directory,
not on a filename. I put another test up there. If you could check
that out I'd appreciate it:
<http://lesscode.org/eggs/somepackage-1.1-py2.4.egg>
The package structure:
somepackage/__init__.py
somepackage/somemodule.py
somepackage/wtf/someresource.txt
somemodule.py is calling resource_filename as follows::
resource_filename(__name__, 'wtf')
This is failing on my end with a KeyError.
The full patch fixes it but if I revert the zip_pre change I get the
KeyError.
>> @@ -703,7 +703,7 @@
>> def __init__(self, module):
>> DefaultProvider.__init__(self,module)
>> self.zipinfo = zipimport._zip_directory_cache
>> [self.loader.archive]
>> - self.zip_pre = self.loader.archive+os.sep
>> + self.zip_pre = self.module_path + os.sep
>> def _short_name(self, path):
>> if path.startswith(self.zip_pre):
>>
>> This is where I was a bit shaky:
>>
>> loader_archive = /path/to/the-egg.egg
>> module_path = /path/to/the-egg.egg/package
>>
>> Shouldn't resource loading be relative to the package directory and
>> not the root of the egg?
>>
>
> zip_pre is used only to remove the front end of path strings in
> order to get them out of the zipimport module's zip directory
> cache. It has to be loader.archive+os.sep, since that's how
> zipimport constructs its cache. So this should not be changed.
It also seems to be used to figure out key names in the zip index and
this seems to be the problem.
> In the meantime, though, I'm definitely paying for my lack of
> upfront testing in several areas, as the entire system has grown
> from a few hundred to a few thousand lines of code.
That's been my experience with unit testing: pay me now or pay me
later, but you'll pay.
Ryan Tomayko
rtomayko at gmail.com
http://naeblis.cx/rtomayko/
More information about the Distutils-SIG
mailing list