Virtualenv: Setuptools v45.0.0 rompe virtualenv en Python 2

Confirmo que este es un problema importante. En OpenStack, la mayoría de las puertas están rotas debido a esto. Ver: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011956.html

Gracias por informar, / me retrasé media hora; pensé que virtualenv usaría el solucionador moderno de pip, pero aparentemente no lo hace.

Ya se ha rastreado en setuptools para otro flujo descendente https://github.com/pypa/setuptools/issues/1963

No estoy seguro de por qué se recogen setuptools 45+, virtualenvs bootstrap debería mantenerlo 44 para setuptools. 🤔

Aquí está el rastreo: http://paste.openstack.org/show/788301/

legacy_resolve suena como algo que descartaría las nuevas reglas.

No, una vía incorrecta para explorar, el pip sin procesar también ignora la restricción de la versión py (a pesar de que se anuncia que funciona): http://paste.openstack.org/show/788302/

Echaré un vistazo y publicaré una solución mañana. Si alguien tiene tiempo para hacer un anuncio antes, eso ayudaría.

@yoctozepto parece que no puede replicar su falla; ¿Puede darnos el registro de creación completo con triple verbosidad?

@gaborbernat Si es el mismo problema que pypa / pip # 7586, entonces esto puede ser un error en uno de los espejos de PyPA que .

Aparentemente, uno de ellos no está propagando correctamente la información python_requires .

Si es así, entonces este es un error para ese espejo; nada que ver con nosotros mismos 🤷‍♂

Lo siguiente me funcionó para salir de este problema.

pip install --upgrade 'setuptools <45.0.0'

Estoy trabajando con un proyecto que todavía usa python 2.7 :(, y tuve el mismo problema.
Pero, usando el comando anterior (por ikrambabai), ¡funcionó de nuevo! :D
¡Gracias!

Sin embargo, esto sigue siendo crítico al crear un nuevo entorno virtual para python 2.7, ya que virtualenv descargaría setuptools-45.0.0 , y ninguna actualización (degradar a través de pip con pip install --upgrade 'setuptools<45.0.0' ) en realidad lo eliminaría . La única solución es descargar la rueda manualmente.

Sin embargo, esto sigue siendo crítico al crear un nuevo entorno virtual para python 2.7, ya que virtualenv descargaría setuptools-45.0.0 , y ninguna actualización (degradar a través de pip con pip install --upgrade 'setuptools<45.0.0' ) en realidad lo eliminaría . La única solución es descargar la rueda manualmente.

Esto solo debería suceder si está detrás de un servidor de índices que no propaga requisitos de python ... así que recomiendo arreglar el servidor de índices.

@gaborbernat no que yo sepa. ¿Hay alguna forma de comprobarlo?

Puedo ver que pythonhosted.org se usa al descargar los paquetes al crear el 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

Pase las banderas -v por pip install setuptools -vvv ?

Eso funciona y la versión correcta 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

El problema surge solo al crear el entorno virtual.

@ostefano A mí me pasó lo mismo. Trabajé alrededor de esto instalando setuptools explícitamente:

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

Nos enfrentamos al mismo problema: https://github.com/mozilla-services/syncserver/issues/239
Primero pensé que pythonhosted.org no respeta la bandera Requires-Python pero con el mismo espejo funciona en Debian Stretch con Python 2.7.13 mientras falla en Ubuntu Xenial con Python 2.7.12, de lo contrario, configuraciones de sistema bastante limpias, incluso probado en un entorno Docker. La versión de Python no puede ser la razón, ya que ya se informó el mismo problema con Ubuntu Bionic y Python 2.7.17.

Entonces, estoy desconcertado dónde / en qué nivel se debe buscar el error, Python, virtualenv, pip, pythonhosted.org o ¿hay algo en el medio?
La solución es clara, pero sería genial investigar y corregir la razón por la que setuptools 45 se extrae en primer lugar.