[Distutils] setuptools bug report: _get_unpatched() is way too clever (and also returns the wrong module)

zooko zooko at zooko.com
Thu Mar 27 03:25:17 CET 2008


On Mar 26, 2008, at 6:56 PM, Phillip J. Eby wrote:
>>
>> https://dev.allmydata.com/buildbot-tahoe/builders/dapper/builds/ 
>> 1427/steps/compile/logs/stdio
>
> That URL requires login credentials that I don't have.  And I need  
> the rest of the traceback to make any sense of this.

My apologies -- I meant:

http://allmydata.org/buildbot/builders/dapper/builds/1427/steps/ 
compile/logs/stdio


> Looking at what limited information you've given me, I doubt the  
> problem has anything to do with this function, whose operation is  
> ridiculously simple - it finds the first base class that wasn't  
> defined by setuptools, and *was* defined by the distutils.  Since  
> the distutils don't define an easy_install *or* develop command,  
> neither one uses _get_unpatched and there should thus be no way  
> that this is causing the weird import situation you have.
>
> This is 99.9% unlikely to be related in *any* way to _get_unpatched 
> (), and I'm only hedging the .1% because I'm cautious by  
> nature.  :)  (Well, that, and there's not a lot of info to go on  
> here.)

Okay, then I admit that _get_unpatched()'s cleverness may not be the  
cause of this bug, but it was certainly the cause of Brian Warner and  
me ceasing to debug this, since we needed to grok _get_unpatched() in  
order to determine that it was not the cause of the problem.


My offer to host an issue tracker for setuptools/easy_install/ 
pkg_resources/eggs is still open.  It could be a good way to organize  
and remember knowledge.


Regards,

Zooko



More information about the Distutils-SIG mailing list