Python Deployment And /usr/bin/env Portability

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 envir

Solution 1:

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 inos.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()
    iflen(plist) == 0: return None
    return plist[0]

Solution 2:

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>

Solution 3:

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

Solution 4:

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.