Informando a versão Python no repositório ao usar o pyenv-virtualenv

5

Eu vim a saber sobre virtualenv e pyenv há algum tempo, e os usou separadamente por um tempo. Recentemente, ao investigar as melhores práticas e ferramentas para o desenvolvimento em Python, encontrei pyenv-virtualenv . Eu acho isso útil (ele cuida de usar o método certo para criar o ambiente virtual dependendo da versão do Python) e limpo (já que o diretório venv não está envolvido na sua base de código).

O problema que encontro é que anteriormente (ao usar pyenv e virtualenv separadamente) eu enviaria meu arquivo requirements.txt e meu arquivo .python-version para o repositório. Ao clonar o projeto, alguns meses depois, eu poderia recriar meu ambiente virtual usando requirements.txt e poderia verificar .python-version para ver em qual versão do Python eu estava desenvolvendo.

Com pyenv-virtualenv , no entanto, o arquivo .python-version é menos útil. Como em pyenv-virtualenv um ambiente virtual é tratado como uma nova versão do Python dentro de pyenv , e a maneira de vincular seu projeto ao ambiente virtual é "definindo a versão do Python" para esse ambiente virtual, o arquivo não contém mais a versão exata do Python que você está usando.

Vamos fingir que estou trabalhando no projeto Euler e decidir criar um ambiente virtual para ele usando pyenv-virtualenv , e eu chamo de project_euler. Para fazer com que minha base de código seja executada nesse ambiente virtual, preciso ir para o diretório do projeto e digitar: pyenv local project_euler .

Agora tudo funciona muito bem localmente, mas quando eu envio meu repositório e o pego novamente em alguns meses, .python-version não será muito útil, já que ele diz apenas "project_euler". Além disso, se a pessoa que faz o download do repositório tiver um virtualenv chamado project_euler , que está configurado diferentemente do que eu estava usando quando eu o enviei, eles podem usar um ambiente configurado incorretamente sem perceber . Isso não foi um problema ao usar pyenv e virtualenv separadamente, já que .python-version incluiu apenas informações sobre a versão do Python, e não o nome do ambiente virtual em uso.

Quais são as melhores práticas para lidar com esses problemas? Eu posso pensar em várias opções:

  • Inclua a versão do Python no nome de seus ambientes virtuais: project_euler_3.5.3 (observe que isso não resolve o problema de usar o ambiente virtual errado por engano).
  • Não envie .python-version , em vez disso, documente a versão mínima suportada do Python no README .
  • Não envie .python-version , e não documente a versão do Python (não parece certo, já que existem problemas de retrocompatibilidade mesmo entre pequenas revisões --eg 3.5 vs 3.4-- então não deve ser da conta usuário ter que adivinhar).
por user2891462 30.06.2017 / 10:43
fonte

2 respostas

1

Eu recomendaria usar o pipenv para o desenvolvimento de python, que resolve vários problemas.

Agora é a ferramenta oficial recomendada em python.org

Se você tem experiência com digamos npm ou algo parecido, o pipenv se comporta de maneira similar. Ele faz sua contabilidade em dois arquivos ( Pipfile e Pipfile.lock ) e ajuda você a criar construções determinísticas . Para obter um ambiente de trabalho, você confirma ambos como faria com um requirements.txt ao lado do código, confira o código, execute pipenv install e voilà. Com pipenv shell você entra em seu ambiente virtual.

No seu Pipfile é uma seção com a finalidade de definir a versão exigida do python, por exemplo,

[requires]
python_version = "3.6"
    
por 08.04.2018 / 09:41
fonte
0

A resposta curta é que com pip / virtualenv você não pode. Ambos supõem que um tempo de execução compatível com o Python esteja instalado (eles são, afinal, pacotes do Python). Especificar a versão no README é o caminho a seguir.

Você pode escrever um script de instalação personalizado, mas é para isso que setuptools serve. Você pode especificar a versão necessária do Python com python_requires em setup.py. Isso fornecerá uma mensagem de erro sensata se o Python necessário não estiver presente e tiver muitas maneiras de lidar com outras necessidades de instalação personalizadas.

Isso pode parecer mais uma maneira de gerenciar versões, mas é o padrão Python e há muitas vantagens, incluindo anos de conhecimento da comunidade.

    
por 07.04.2018 / 21:35
fonte