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 s
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 end 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.
Update: If you know what you are doing, you can do this:
/path/to/install/python setup.py build -e "/the/path/you/want/python" install
Make sure you clean the build directory first though. :)
In one of the latest versions of distutils, there is a flag --no-autoreq that have worked for me:
--no-autoreq do not automatically calculate dependencies
In my case, I was creating RPM files with python2.4 executable, in a server with both 2.4 and 2.6 installations. bdist just left the shebangs as they were, after running:
python setup.py bdist_rpm --no-autoreq
In the case that you are handling the spec files, you may use the solution explained at https://stackoverflow.com/a/7423994/722997, adding:
AutoReq: no
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.
had the same issue. tried to find a way to prevent the touching altogether by default. here is the solution. essentially we override the default script copy routine (build_scripts).
in setup.py add
from distutils.command.build_scripts import build_scripts
# don't touch my shebang
class BSCommand (build_scripts):
def run(self):
"""
Copy, chmod each script listed in 'self.scripts'
essentially this is the stripped
distutils.command.build_scripts.copy_scripts()
routine
"""
from stat import ST_MODE
from distutils.dep_util import newer
from distutils import log
import os
self.mkpath(self.build_dir)
outfiles = []
for script in self.scripts:
outfile = os.path.join(self.build_dir, os.path.basename(script))
outfiles.append(outfile)
if not self.force and not newer(script, outfile):
log.debug("not copying %s (up-to-date)", script)
continue
log.info("copying and NOT adjusting %s -> %s", script,
self.build_dir)
self.copy_file(script, outfile)
if os.name == 'posix':
for file in outfiles:
if self.dry_run:
log.info("changing mode of %s", file)
else:
oldmode = os.stat(file)[ST_MODE] & 0o7777
newmode = (oldmode | 0o555) & 0o7777
if newmode != oldmode:
log.info("changing mode of %s from %o to %o",
file, oldmode, newmode)
os.chmod(file, newmode)
setup(name="name",
version=version_string,
description="desc",
...
test_suite='testing',
cmdclass={'build_scripts': BSCommand},
)
.. ede/duply.net
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