homepage

This scenario fails:
 python setup.py install
 python3 setup.py install
Because it seems like code once built for Python 2 is not rebuild when installing for Python 3.

Could you please be more specific about what you are trying to do and what error you are seeing?

I've had the same issue. I was installing Pyglet. I first installed it under Python 2, then:
$ sudo python3 setup.py install
running install
running build
running build_py
running install_lib
[...]
creating /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/window/xlib
copying build/lib/pyglet/window/xlib/__init__.py -> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/window/xlib
byte-compiling /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/__init__.py to __init__.cpython-32.pyc
 File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/__init__.py", line 276
 print '[%d] %s%s %s' % (thread, indent, name, location)
 ^
SyntaxError: invalid syntax
Deleting the 'build' directory from the Python 2 run fixed the problem and I could install the package under Python 3.

It seems to me this is just a special case of the more general issue of building multiple versions of the same distribution, say with multiple versions of Python 2. In general, anytime you change your build environment, you should start with no existing build directory. That's just good practice. Distutils doesn't keep track of every change you might make in a build environment between invocations of setup.py. I suggest that this be closed as "won't fix".

> It seems to me this is just a special case of the more general issue of building multiple versions of the
> same distribution, say with multiple versions of Python 2. In general, anytime you change your build
> environment, you should start with no existing build directory.
Maybe Distutils could do that for you.
> Distutils doesn't keep track of every change you might make in a build environment between invocations
> of setup.py.
Could you detail what you mean with "change in a build environment"? Timestamps are tracked, C headers dependencies too, changes to setup.py (and maybe setup.cfg too), so I think it wouldn’t be a stretch to also track the Python version used to run setup.py. On the other hand, even with the same version there can be differences in the command-line options, the available modules (using Pythons with the same version from different virtual environments), etc. Anyway, using one build directory per version (X.Y.Z) could easily solve a part of these issues.
What do people think?

Currently users can run e.g.:
$ python2.7 setup.py build -b build-2.7 install
$ python3.2 setup.py build -b build-3.2 install
If default name of build directory had to be changed, then it would be useful to also include name of Python implementation (e.g. "build-cpython-2.7").

I'd change the name of the subdirectories of build instead of the name of the build directory itself. That way distutils will still create one build directory regardless of how many python versions you use, and the name of that directory is easily predicatble (which is nice when using basic tools to clean up a directory).
The distribute/setuptools projects do this as well, and implementing this should only require a fairly trival patch to distutils.commands.build (the defaults for the various build_ directories need to be updated).
BTW. How likely is the acceptance of such a patch? IIRC distutils is more or less closed for development w.r.t. new features. Would that also apply to this feature request?

> I'd change the name of the subdirectories of build instead of the name of the build directory itself.
Yep that’s what I was thinking about (or if I wasn’t, I should have been :)
> IIRC distutils is more or less closed for development w.r.t. new features.
Not more or less: it is frozen. The only exceptions are changes required by other changes like the pycache or ABI tag PEPs.
> Would that also apply to this feature request?
If we agree this is a bug, we can fix it. What do RMs think?

Changing of name of subdirectory would break e.g. shell scripts, which set PYTHONPATH=build/lib when calling Python scripts, so this change rather should not be made in micro releases.

I don't think this is a bugfix, but a new feature and as such the behavior should only be changed for 3.4.
The easiest workaround for this issue is to use setuptools or distribute when installing, as those tools do set the various build directories to version-specific values.

Okay, then it’s distutils2 material.

A doc note for distutils in stable versions could also be added.

setuptools is recommended over distutils, and doesn’t have the issue (per previous messages).