Virtualenv: Setuptools v45.0.0 quebra o virtualenv no Python 2

Criado em 12 jan. 2020 · 18Comentários · Fonte: pypa/virtualenv

Prefácio : estou bastante familiarizado com todo o prazo final de 1º de janeiro de 2020 e estou no processo de descartar o Python 2 em todos os meus projetos, mas essa surpresa das ferramentas de instalação é bastante inconveniente de qualquer maneira. Se você optou por não consertar isso, não julgarei ninguém, mas por favor, não me fale sobre o Python 2 estar obsoleto :-)

Todos os meus scripts de criação de ambiente virtual automatizado no Python 2 começaram a quebrar hoje.

Aqui está um exemplo:

$ py -2.7-32 -m virtualenv foo
…
UnsupportedPythonVersion: Package 'setuptools' requires a different Python: 2.7.8 not in '>=3.5'
…
OSError: Command …\Scripts\python.exe - setuptools pip wheel failed with error code 1

Isso parece ser causado pelo lançamento de setuptools v45.0.0 ontem:

v45.0.0: 11 de janeiro de 2020
1458: Abandone o suporte para Python 2. Setuptools agora requer Python 3.5 ou posterior. Instale ferramentas de instalação usando pip> = 9 ou fixe nas ferramentas de instalação <45 para manter o suporte 2.7.
1959: Correção para Python 4: substitua inseguro six.PY3 por six.PY2
https://setuptools.readthedocs.io/en/latest/history.html#v45 -0-0

Parece que, por padrão, virtualenv tenta instalar as ferramentas de instalação mais recentes e pip install setuptools pega setuptools>=45.0.0 , embora essas versões não suportem Python 2.

Como solução alternativa, agora estou usando os seguintes comandos:

$ py -2.7-32 -m virtualenv --no-setuptools foo
$ foo\Scripts\python -m pip install "setuptools<45"

Não sou nenhum produto de exportação em pacotes Python, mas espero que setuptools>=45 declare que não suporta Python 2 em seus metadados de distribuição e que pip install setuptools detectaria isso automaticamente e o evitaria, mas isso não parece ser o caso.

Se isso não for possível, talvez as versões de virtualenv para Python 2 devam evitar setuptools>=45 ?

Fonte

AndreLouisCaron

👍15

Comentários muito úteis

O seguinte funcionou para eu sair desse problema.

pip install --upgrade 'setuptools <45.0.0'

ikrambabai em 20 jan. 2020

👍52 🎉10 ❤7 🚀1

Todos 18 comentários

Eu confirmo que este é um grande problema. No OpenStack, a maioria das portas está quebrada devido a isso. Consulte: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011956.html

Obrigado por relatar, / me atrasado em meia hora - pensei que o virtualenv usaria o resolvedor moderno do pip, mas aparentemente não usa.

yoctozepto em 12 jan. 2020

Já rastreado no setuptools para outro downstream https://github.com/pypa/setuptools/issues/1963

yoctozepto em 12 jan. 2020

Não sei por que o setuptools 45+ foi escolhido, o bootstrap do virtualenvs deve mantê-lo 44 para setuptools. 🤔

gaborbernat em 12 jan. 2020

Aqui está o traceback: http://paste.openstack.org/show/788301/

legacy_resolve soa como algo que descartaria as novas regras.

yoctozepto em 12 jan. 2020

Nah, caminho errado para explorar, o pip bruto também ignora a restrição da versão py (apesar de ser anunciado como funcionando): http://paste.openstack.org/show/788302/

yoctozepto em 12 jan. 2020

Vou dar uma olhada e liberar uma correção amanhã. Se alguém tiver tempo para fazer um relatório antes isso ajudaria.

gaborbernat em 12 jan. 2020

@yoctozepto não consegue reproduzir seu fracasso; você pode nos dar o log de criação completo com verbosidade tripla?

gaborbernat em 12 jan. 2020

@gaborbernat Se for o mesmo problema que pypa / pip # 7586, então pode ser um bug em um dos mirrors PyPA que @yoctozepto está usando .

Aparentemente, um deles não está propagando as informações python_requires corretamente.

pganssle em 12 jan. 2020

Se sim, então este é um bug para aquele espelho; nada a ver conosco 🤷‍♂

gaborbernat em 12 jan. 2020

O seguinte funcionou para eu sair desse problema.

pip install --upgrade 'setuptools <45.0.0'

ikrambabai em 20 jan. 2020

👍52 🎉10 ❤7 🚀1

Estou trabalhando em um projeto que ainda usa o python 2.7 :( e tive o mesmo problema.
Mas, usando o comando acima (por ikrambabai), funcionou de novo !! : D
Obrigado!

pamelars86 em 21 jan. 2020

No entanto, isso ainda é crítico ao criar um novo ambiente virtual para python 2.7, uma vez que virtualenv baixaria setuptools-45.0.0 , e nenhuma atualização (downgrade via pip com pip install --upgrade 'setuptools<45.0.0' ) iria realmente removê-lo . A única solução é baixar o volante manualmente.

ostefano em 24 jan. 2020

👍1

No entanto, isso ainda é crítico ao criar um novo ambiente virtual para python 2.7, uma vez que virtualenv baixaria setuptools-45.0.0 , e nenhuma atualização (downgrade via pip com pip install --upgrade 'setuptools<45.0.0' ) iria realmente removê-lo . A única solução é baixar o volante manualmente.

Isso só deve acontecer se você estiver atrás de um servidor de indexação que não propague python-require ... portanto, recomendo consertar o servidor de indexação.

gaborbernat em 24 jan. 2020

@gaborbernat que eu saiba. Existe uma maneira de eu verificar isso?

Posso ver que pythonhosted.org é usado ao baixar os pacotes ao criar o virtualenv:

Installing setuptools, pkg_resources, pip, wheel...
  Running command /opt/llenv22/bin/python2.7 - setuptools pkg_resources pip wheel
  Collecting setuptools
    Using cached https://files.pythonhosted.org/packages/af/e7/02db816dc88c598281bacebbb7ccf2c9f1a6164942e88f1a0fded8643659/setuptools-45.0.0-py2.py3-none-any.whl
  Collecting pkg_resources
  Collecting pip
    Using cached https://files.pythonhosted.org/packages/54/0c/d01aa759fdc501a58f431eb594a17495f15b88da142ce14b5845662c13f3/pip-20.0.2-py2.py3-none-any.whl
  Collecting wheel
    Using cached https://files.pythonhosted.org/packages/00/83/b4a77d044e78ad1a45610eb88f745be2fd2c6d658f9798a15e384b7d57c9/wheel-0.33.6-py2.py3-none-any.whl

ostefano em 24 jan. 2020

Passar os sinalizadores -v para pip install setuptools -vvv ?

gaborbernat em 24 jan. 2020

Isso funciona e a versão correta está instalada:

Collecting setuptools
  Created temporary directory: /tmp/pip-unpack-zJMfUH
  Starting new HTTPS connection (1): files.pythonhosted.org:443
  https://files.pythonhosted.org:443 "GET /packages/f9/d3/955738b20d3832dfa3cd3d9b07e29a8162edb480bf988332f5e6e48ca444/setuptools-44.0.0-py2.py3-none-any.whl HTTP/1.1" 200 583230
  Downloading setuptools-44.0.0-py2.py3-none-any.whl (583 kB)
     |████████████████████████████████| 583 kB 3.3 MB/s
  Added setuptools from https://files.pythonhosted.org/packages/f9/d3/955738b20d3832dfa3cd3d9b07e29a8162edb480bf988332f5e6e48ca444/setuptools-44.0.0-py2.py3-none-any.whl#sha256=180081a244d0888b0065e18206950d603f6550721bd6f8c0a10221ed467dd78e to build tracker '/tmp/pip-req-tracker-OTDORt'
  Removed setuptools from https://files.pythonhosted.org/packages/f9/d3/955738b20d3832dfa3cd3d9b07e29a8162edb480bf988332f5e6e48ca444/setuptools-44.0.0-py2.py3-none-any.whl#sha256=180081a244d0888b0065e18206950d603f6550721bd6f8c0a10221ed467dd78e from build tracker '/tmp/pip-req-tracker-OTDORt'
Installing collected packages: setuptools
  Created temporary directory: /tmp/pip-unpacked-wheel-vDEYe

O problema surge apenas ao criar o ambiente virtual.

ostefano em 24 jan. 2020

@ostefano Foi o mesmo comigo. Eu contornei isso instalando setuptools explicitamente:

$ py -2.7-32 -m virtualenv --no-setuptools foo
$ foo\Scripts\python -m pip install "setuptools<45"

AndreLouisCaron em 26 jan. 2020

👍4

Enfrentamos o mesmo problema: https://github.com/mozilla-services/syncserver/issues/239
Primeiro pensei que o pythonhosted.org não respeitava a sinalização Requires-Python mas com o mesmo espelho funciona no Debian Stretch com Python 2.7.13 enquanto falha no Ubuntu Xenial com Python 2.7.12, caso contrário, configurações de sistema bem limpas, até mesmo testado em um ambiente Docker. A versão Python não pode ser o motivo, pois o mesmo problema já foi relatado com Ubuntu Bionic e Python 2.7.17.

Portanto, estou um lance intrigado onde / em que nível o bug precisa ser pesquisado, Python, virtualenv, pip, pythonhosted.org ou há algo no meio?
A solução alternativa é clara, mas seria ótimo investigar e corrigir o motivo pelo qual o setuptools 45 foi puxado em primeiro lugar.