For a long time, I have been annoyed by distutils behavior concerning
"scripts": I always put
into the first line in order to let the incredibly useful "env" program start
the right python version.
I know that it is quite evil to hardcode /usr/bin/python
or /usr/local/bin/python; I have seen dozens of #! hacks for finding e.g.
perl, and I was delighted to find /usr/bin/env, which solves the problem once
and for all. (And yes - it is always in /usr/bin/! ;-) )
Now distutils tries to be intelligent and "destroys" my nice #! lines, which
can be quite evil in complex setups, e.g. when you share your home directory
via NFS (or rsync/unison) between several environments with different python
installations. Furthermore, we are using the "module" system here at our
university, so that I can dynamically choose between half a dozen python
versions ("module" manages your PATH variables). Replacing the python path
turns nice, pure python scrips into platform-specific programs as you can see
meine@kogspc12:~ head -n1 ~/vigra/interactive/build/scripts-2.4/pyterm
Note the SuSE-9.0 exec-prefix in the path; we are using several Linux and
Solaris versions here:
meine@kogspc12:~/tmp/vi3build -> ls -1 /software/python-2.4.4/*/bin/python
I see that distutils as it is now does the right thing
* on Windows systems,
* on any system where /usr/bin/env is missing, or
* when the source file has a #! with a broken path.
What I propose is a minimal invasive change which keeps /usr/bin/env iff it is
in the #! line *and* exists on the current system. (A more brave change
would be to always use /usr/bin/env if it exists, but I think that is a topic
open for discussion.) Attached you'll find a patch which implements this; I
did not yet update tests/test_build_scripts.py however.
Ciao, / /
/ / ANS