Don't touch my shebang!

Question

One thing I hate about distutils (I guess he is the evil who does this) is that it changes the shebang line. In other words, the more rational and environment-vars decided scripture

#!/usr/bin/env python

gets magically converted into

#!/whatever/absolute/path/is/my/python

This is seen also with grok: I used grokproject in a virtualenv to start my project, but now I cannot move the development directory around anymore, because it puts absolute paths in the shebang directive.

The reason why I ask this is twofold

• I want to move it around because I started developing in one directory (Experiments) and now I want to move it into a proper path, but I could not do it. So I created a new virtualenv and grokproject and copied my files. That fixes the issue, but leaves my curiosity for a more rational solution unsatisfied. In particular, if the reference to the virtualenv python interpreter was relative, the problem would not have been present in the first place. You know the layout of the virtualenv, and you can refer to the virtualenv python easily.
• The second reason is that I would like to be able to scp the virtualenv to another computer and run it there without trouble. This is not possible if you have hardcoded paths.

Answer 1

I have no solution to your problem, but I do see some rationale for the current behaviour of distutils.

#!/usr/bin/env python executes the system's default Python version. That is fine as long as your code is compatible with said version. When the default version is updated (from 2.5 to 3, say) your code or other Python code which references /usr/bin/env may stop working, even though the old Python version is still installed. For that reason it makes sense to "hardcode" the path to the appropriate python interpreter.

Edit: you are correct in asserting that specifying python2.4 or similar solves this problem.

Edit 2: things are not as clear cut when multiple installations of the same Python version are present, as Ned Deily points out in the comments below.

Answer 2

Of course you can move the development directory around. Distutils changes the paths to the python that you should run with when you run it. It's in Grok run when you run the buildout. Move and re-run the bootstrap and the buildout. Done!

Distutils changes the path to the Python you use to run distutils with. If it didn't, then you might up installing a library in one python version, but when you try to run the script it would fail, because it would run with another python version that didn't have the library.

That's not insanity, it's in fact the only sane way to do it.

Answer 3

Distutils will automatically replace the shebang with the location of the Python binary that was used to execute setup.py. To override this behavior you have two options:

Option 1: Manually

You may pass the flag --executable=/path/to/my/python to setup.py. Arguments are accepted.

Example:

% python setup.py build --executable=/opt/local/bin/python -d

Option 2: Automatically

Your other option is to add a line to setup.cfg. If you aren't using setup.cfg, create it in the same directory as setup.py. Setup.py looks for this on startup. Any options specified here can still be overridden with flags at the command-line.

% cat setup.cfg 
[build]
executable = /opt/local/bin/python -d