[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:


The package structure:


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  

>> @@ -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

More information about the Distutils-SIG mailing list