Python deployment and /usr/bin/env portability

Question

At the beginning of all my executable Python scripts I put the shebang line:

#!/usr/bin/env python

I'm running these scripts on a system where env python yields a Python 2.2 environment. My scripts quickly fail because I have a manual check for a compatible Python version:

if sys.version_info < (2, 4):
    raise ImportError("Cannot run with Python version < 2.4")

I don't want to have to change the shebang line on every executable file, if it's possible; however, I don't have administrative access to the machine to change the result of env python and I don't want to force a particular version, as in:

#!/usr/bin/env python2.4

I'd like to avoid this because system may have a newer version than Python 2.4, or may have Python 2.5 but no Python 2.4.

What's the elegant solution?

[Edit:] I wasn't specific enough in posing the question -- I'd like to let users execute the scripts without manual configuration (e.g. path alteration or symlinking in ~/bin and ensuring your PATH has ~/bin before the Python 2.2 path). Maybe some distribution utility is required to prevent the manual tweaks?

Answer 1

"env" simply executes the first thing it finds in the PATH env var. To switch to different python, prepend the directory for that python's executable to the path before invoking your script.

Answer 2

Pretty hackish solution - if your check fails, use this function (which probably could be significantly improved) to determine the best interpreter available, determine if it is acceptable, and if so relaunch your script with os.system or something similar and your sys.argv using the new interpreter.

import os
import glob
def best_python():
    plist = []
    for i in os.getenv("PATH").split(":"):
        for j in glob.glob(os.path.join(i, "python2.[0-9]")):
             plist.append(os.path.join(i, j))
    plist.sort()
    plist.reverse()
    if len(plist) == 0: return None
    return plist[0]

Answer 3

If you are running the scripts then you can set your PATH variable to point to a private bin directory first:

$ mkdir ~/bin
$ ln -s `which python2.4` ~/bin/python
$ export PATH=~/bin:$PATH

Then when you execute your python script it'll use python 2.4. You'll have to change your login scripts to change your PATH.

Alternatively run your python script with the explicit interpreter you want:

$ /path/to/python2.4 <your script>

Answer 4

@morais: That's an interesting idea, but I think maybe we can take it one step farther. Maybe there's a way to use Ian Bicking's virtualenv to:

• See if we're running in an acceptable environment to begin with, and if so, do nothing.
• Check if there exists a version-specific executable on the PATH, i.e. check if python2.x exists for x in reverse(range(4, 10)). If so, re-run the command with the better interpreter.
• If no better interpreter exists, use virtualenv to try and install a newer version of Python from the older version of Python and get any prerequisite packages.

I have no idea if virtualenv is capable of this, so I'll go mess around with it sometime soon. :)

Answer 5

Here's a solution if you're (1) absolutely set on using shebangs and (2) able to use Autotools in your build process.

I just found last night that you can use the autoconf macro AM_PATH_PYTHON to find a minimal Python 2 binary. The how-to is here.

So, your process would be:

• Issue an AM_PATH_PYTHON(2.4) in your configure.ac
• Rename all of your .py scripts to .py.in (in my experience, this doesn't confuse vi)
• Name all of those Python scripts you want to generate with AC_CONFIG_FILES.
• Instead of starting with #!/usr/bin/env python, use #!@PYTHON@

Then your resultant Python scripts will always have an appropriate shebang.

So, you have this solution, at least possible, if not practical.