I have the following setup.py script:

#!/usr/bin/env python
from distutils.core import setup

scripts=["hello.py"]

setup(scripts=scripts)

I have two different python installations (using virtualenv) where I
wish to install this program. So I do

~/tmp/test_setup/python1/bin/python setup.py install

which creates a file at
/users/geoff/tmp/test_setup/python1/bin/hello.py, that looks like
this:

#!/users/geoff/tmp/test_setup/python1/bin/python

print "Hello"

So far so good. But then I also install it somewhere else:

~/tmp/test_setup/python2/bin/python setup.py install

which creates a file at
/users/geoff/tmp/test_setup/python2/bin/hello.py which refers to
"python1", i..e it has the same contents as the first one. Which is
clearly not what I want.

The cached script in the build tree appears not to get updated once it exists.

As described in distutils-SIG, we need to work on a clever way to update the build tree.

For Distutils1, removing it completely (possibly via the clean command) is what people can do.

For this particular bug, we could add a check for the shebang line in distutils1’ build_scripts, so that a second run can detect it should rebuild the scripts even though the source has not changed.  Or is there a rule that says build_* command only look at timetamps to decide that?

I agree about the larger problem that cannot be solved entirely and nicely in distutils2.

I now think that this should be fixed in d1 too.  We could just always rebuild scripts (it’s just a file copy), or implement the matching idea from my previous message.

To answer my own question:
> Or is there a rule that says build_* command only look at timetamps to decide that?
I think a command is free to do whatever inspection it needs to determine is something needs rebuilding.

Tests would need to exercise both the --executable option of build_scripts and default value.  Thankfully the code uses sys.executable and we can inject a custom value in a test.  Adding the easy keyword, I think this is a good candidate for the upcoming Montreal sprint.

In distutils2, 99382aafa4c5 forces scripts to always be rebuilt and 463d3014ee4a goes further and deletes the whole build dir to avoid installing scripts built from a previous build call with a different configuration (i.e. different list of scripts).

The same issue may affect other build commands; if a module is built and then removed from the source dir and setup.cfg/.py, I think the install command would still install it.  The dependency code should take setup.cfg and files referenced from hooks to decide if the source is newer, and it should delete built files for which there is no source.