implantação Python e / usr / bin / env portabilidade

votos
12

No início de todos os meus scripts executável Python Eu coloquei o shebang linha:

#!/usr/bin/env python

Estou executando esses scripts em um sistema onde env pythonproduz um ambiente Python 2.2. Meus scripts rapidamente falhar, porque eu tenho uma verificação manual para uma versão Python compatível:

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

Eu não quero ter que mudar a linha shebang em cada arquivo executável, se for possível; no entanto, eu não tenho acesso administrativo para o aparelho para mudar o resultado de env pythone eu não quero forçar uma versão específica, como em:

#!/usr/bin/env python2.4

Eu gostaria de evitar isso porque o sistema pode ter uma versão mais recente do que o Python 2.4, ou pode ter Python 2.5, mas não Python 2.4.

Qual é a solução elegante?

[Edit:] Eu não era suficientemente específico em colocar a questão - Eu gostaria de permitir que os usuários executar os scripts sem configuração manual (alteração por exemplo caminho ou link simbólico em ~/bine garantindo o seu caminho tem ~/binantes do caminho Python 2.2). Talvez alguma concessionária de distribuição é necessária para evitar que os ajustes manuais?

Publicado 02/09/2008 em 22:21
fonte usuário
Em outras línguas...                            


5 respostas

votos
8

"Env" simplesmente executa a primeira coisa que encontra no PATH env var. Para mudar para python diferente, preceder o diretório para que o python do executável para o caminho antes de invocar o seu script.

Respondeu 02/09/2008 em 22:25
fonte usuário

votos
4

solução bastante hackish - se a sua verificação falhar, utilize esta função (que provavelmente poderia ser significativamente melhorada) para determinar a melhor intérprete disponíveis, determinar se é aceitável, e se assim relançar o seu script com os.system ou algo semelhante e seus sys. argv usando o novo intérprete.

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]
Respondeu 03/09/2008 em 21:32
fonte usuário

votos
2

Se você estiver executando os scripts em seguida, você pode definir a variável PATH para apontar para um diretório bin privado em primeiro lugar:

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

Então, quando você executar o script python que vai usar python 2.4. Você vai ter que mudar seus scripts de login para alterar o seu PATH.

Alternativamente executar o script python com o intérprete explícita que você deseja:

$ /path/to/python2.4 <your script>
Respondeu 02/09/2008 em 22:28
fonte usuário

votos
0

Aqui está uma solução se você é (1) absolutamente definir sobre o uso de 'shebangs e (2) capaz de usar Autotools em seu processo de criação.

Eu só descobri ontem à noite que você pode usar a macro autoconf AM_PATH_PYTHONpara encontrar um mínimo Python 2 binário. O how-to é aqui .

Assim, seu processo seria:

  • Emitir um AM_PATH_PYTHON(2.4)na suaconfigure.ac
  • Renomear todos os seus .pyscripts para .py.in(na minha experiência, isso não confundir vi)
  • Nome todos esses scripts Python você deseja gerar com AC_CONFIG_FILES.
  • Em vez de começar com #!/usr/bin/env python, use#!@PYTHON@

Em seguida, seus resultantes scripts Python terá sempre uma shebang apropriado.

Então, você tem esta solução, pelo menos possível, se não é prático.

Respondeu 04/10/2013 em 19:27
fonte usuário

votos
0

@morais: Essa é uma idéia interessante, mas acho que talvez possamos dar um passo mais longe. Talvez haja uma maneira de usar virtualenv de Ian Bicking para:

  • Veja se nós estamos correndo em um ambiente adequado para começar, e se assim for, não fazer nada.
  • Verifique se existe um executável específico da versão sobre a PATH, ou seja, verificar se python2.xexiste for x in reverse(range(4, 10)). Se assim for, re-executar o comando com o melhor intérprete.
  • Se não houver uma melhor intérprete, usar virtualenv para tentar instalar uma versão mais recente do Python a partir da versão mais antiga do Python e obter quaisquer pacotes de pré-requisitos.

Eu não tenho idéia se virtualenv é capaz disso, então eu vou mexer com ele em breve. :)

Respondeu 04/09/2008 em 00:07
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more