Déploiement Python et portabilité /usr/bin/env

Question

Au début de tous mes scripts Python exécutables, je mets le case doubler:

#!/usr/bin/env python

J'exécute ces scripts sur un système où env python donne un environnement Python 2.2.Mes scripts échouent rapidement car j'ai une vérification manuelle d'une version Python compatible :

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

Je ne veux pas avoir à changer la ligne shebang sur chaque fichier exécutable, si c'est possible ;cependant, je n'ai pas d'accès administrateur à la machine pour modifier le résultat de env python et je ne veux pas forcer une version particulière, comme dans :

#!/usr/bin/env python2.4

J'aimerais éviter cela car le système peut avoir une version plus récente que Python 2.4, ou peut avoir Python 2.5 mais pas de Python 2.4.

Quelle est la solution élégante ?

[Edit :] Je n'ai pas été assez précis en posant la question : j'aimerais permettre aux utilisateurs d'exécuter les scripts sans configuration manuelle (par ex.modification du chemin ou création de liens symboliques dans ~/bin et en vous assurant que votre PATH a ~/bin avant le chemin Python 2.2).Peut-être qu'un utilitaire de distribution est nécessaire pour empêcher les ajustements manuels ?

Answer 1

"env" exécute simplement la première chose qu'il trouve dans la variable d'environnement PATH.Pour passer à un autre python, ajoutez le répertoire de l'exécutable de ce python au chemin avant d'appeler votre script.

Answer 2

Solution assez hackish - si votre vérification échoue, utilisez cette fonction (qui pourrait probablement être considérablement améliorée) pour déterminer le meilleur interprète disponible, déterminer s'il est acceptable et, si c'est le cas, relancez votre script avec os.system ou quelque chose de similaire et votre système. argv en utilisant le nouvel interpréteur.

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

Si vous exécutez les scripts, vous pouvez d'abord définir votre variable PATH pour qu'elle pointe vers un répertoire bin privé :

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

Ensuite, lorsque vous exécuterez votre script python, il utilisera python 2.4.Vous devrez modifier vos scripts de connexion pour modifier votre PATH.

Vous pouvez également exécuter votre script Python avec l'interpréteur explicite de votre choix :

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

Answer 4

@morais :C'est une idée intéressante, mais je pense que nous pouvons peut-être aller plus loin.Il y a peut-être un moyen d'utiliser L'environnement virtuel de Ian Bicking à:

• Voyez si nous fonctionnons dans un environnement acceptable pour commencer, et si c'est le cas, ne faites rien.
• Vérifiez s'il existe un exécutable spécifique à la version sur le PATH, c'est à dire.vérifier si python2.x existe for x in reverse(range(4, 10)).Si tel est le cas, réexécutez la commande avec le meilleur interpréteur.
• S'il n'existe pas de meilleur interpréteur, utilisez virtualenv pour essayer d'installer une version plus récente de Python à partir de l'ancienne version de Python et obtenir les packages prérequis.

Je ne sais pas si virtualenv est capable de cela, alors je vais bientôt m'en occuper.:)

Answer 5

Voici une solution si vous êtes (1) absolument déterminé à utiliser des shebangs et (2) capable d'utiliser Autotools dans votre processus de construction.

J'ai découvert hier soir que l'on pouvait utiliser la macro autoconf AM_PATH_PYTHON trouver un Python minimal 2 binaire.Le comment faire est ici.

Ainsi, votre processus serait :

• Émettre un AM_PATH_PYTHON(2.4) dans ton configure.ac
• Renommez tous vos .py des scripts pour .py.in (d'après mon expérience, cela ne prête pas à confusion vi)
• Nommez tous les scripts Python avec lesquels vous souhaitez générer AC_CONFIG_FILES.
• Au lieu de commencer par #!/usr/bin/env python, utiliser #!@PYTHON@

Alors votre résultant Les scripts Python auront toujours un shebang approprié.

Vous avez donc cette solution, au moins possible, sinon pratique.