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

[Phillip J. Eby]

At 07:25 PM 3/26/2008 -0700, zooko wrote:
>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

Okay, looking at that, my guess is that the problem is due to the 
fact that setuptools 0.6c8 and its 'site.py' aren't installed until 
the "develop" command is run, and somehow causing the setuptools 
package to get split across two locations.  I would suggest that your 
makefile should ensure the desired version of setuptools is installed 
before anything else.  If that doesn't fix it, my next guess would be 
that Nevow's setup script is altering sys.path in some way, or that 
that or some other setup script tries to forcibly evict or reload 
setuptools.  That's about the only other way I can see for this to 
get split across two locations like that.

Are you using an ez_setup anywhere in there that monkeys with sys.modules?


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

I don't really see how it relates in any way, since it's not listed 
in the traceback.  In any event, the traceback itself also appears 
unrelated to whatever problem Nevow's setup is having.