[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