<br><br><div class="gmail_quote">On 23 July 2012 23:27, Éric Araujo <span dir="ltr"><<a href="mailto:merwok@netwok.org" target="_blank">merwok@netwok.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 22/07/2012 15:57, R. David Murray wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not familiar with distutils, really, so you could be right about<br>
what it is important to test. I was commenting based on the code<br>
snippet presented, which just deciding which "build" object to use.<br>
If build_py_2to3 can be imported by python2 and subsequently screws up<br>
the build, then yes the logic is incorrect.<br>
</blockquote>
<br></div>
That can’t happen. The *_2to3 classes (don’t forget build_scripts_2to3) only exist in 3.x and work with a version check or an import with fallback. There is no cross-version-build at all in distutils.<br></blockquote><div>
<br></div><div>I'm regretting the fact that I didn't keep notes of exactly what I was doing and I can't reproduce this now but this did happen to me when using one of pip/easy_install in a virtualenv. As I said earlier it may have been a mistake on my part as I'm not confident with virtualenv.</div>
<div><br></div><div>At the time when I looked at the files in my pretty much empty virtualenv the main things I could see where related to setuptools so I guessed that some kind of setuptools monkey-patch had made build_py_2to3 importable and changed the setup.py to an explicit version check which fixed the problem in that environment.</div>
<div><br></div><div>Oscar.</div></div>