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

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. :)

Answer 2

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

Answer 3

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

Answer 4

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 5

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