Virtualenv: Setuptools v45.0.0 casse virtualenv sur Python 2

Je confirme que c'est un problème majeur. Dans OpenStack, la plupart des portes sont cassées à cause de cela. Voir : http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011956.html

Merci pour le signalement, /me en retard d'une demi-heure - je pensais que virtualenv utiliserait le résolveur moderne du pip, mais ce n'est apparemment pas le cas.

Déjà suivi dans setuptools pour un autre en aval https://github.com/pypa/setuptools/issues/1963

Vous ne savez pas pourquoi setuptools 45+ est récupéré, virtualenvs bootstrap devrait le garder 44 pour setuptools. ??

Voici le retraçage : http://paste.openstack.org/show/788301/

legacy_resolve ressemble à quelque chose qui rejetterait les nouvelles règles.

Non, mauvaise piste à explorer, raw pip ignore également la contrainte de version py (bien qu'il soit annoncé comme fonctionnel): http://paste.openstack.org/show/788302/

Je vais regarder et publier un correctif demain. Si quelqu'un a le temps de faire un pr avant cela pourrait aider.

@yoctozepto ne semble pas pouvoir reproduire votre échec ; pouvez-vous nous donner le journal de création complet avec une triple verbosité ?

@gaborbernat S'il s'agit du même problème que pypa/pip#7586, cela peut être un bogue dans l' un des miroirs PyPA que @yoctozepto utilise .

Apparemment, l'un d'entre eux ne propage pas correctement les informations python_requires .

Si c'est le cas, alors c'est un bogue pour ce miroir ; rien a voir avec nous

Ce qui suit a fonctionné pour moi de sortir de ce problème.

pip install --upgrade 'setuptools<45.0.0'

Je travaille sur un projet qui utilise toujours python 2.7 :(, et j'ai eu le même problème.
Mais, en utilisant la commande ci-dessus (par ikrambabai), cela a fonctionné à nouveau !! :RÉ
Merci!

Cependant, cela reste essentiel lors de la création d'un nouvel environnement virtuel pour python 2.7, car virtualenv téléchargerait setuptools-45.0.0 , et aucune mise à niveau (rétrogradation via pip avec pip install --upgrade 'setuptools<45.0.0' ) ne le supprimerait réellement . La seule solution est de télécharger la roue manuellement.

Cependant, cela reste essentiel lors de la création d'un nouvel environnement virtuel pour python 2.7, car virtualenv téléchargerait setuptools-45.0.0 , et aucune mise à niveau (rétrogradation via pip avec pip install --upgrade 'setuptools<45.0.0' ) ne le supprimerait réellement . La seule solution est de télécharger la roue manuellement.

Cela ne devrait se produire que si vous êtes derrière un serveur d'index qui ne propage pas python-requires... je vous recommande donc de réparer le serveur d'index.

@gaborbernat pas à ma connaissance. Y a-t-il un moyen pour moi de le vérifier?

Je peux voir que pythonhosted.org est utilisé lors du téléchargement des packages lors de la création du 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

Passez les drapeaux -v pour pip install setuptools -vvv ?

Cela fonctionne et la bonne version est installée :

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

Le problème ne se pose que lors de la création de l'environnement virtuel.

@ostefano C'était pareil pour moi. J'ai contourné cela en installant setuptools explicitement :

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

Nous avons rencontré le même problème : https://github.com/mozilla-services/syncserver/issues/239
J'ai d'abord pensé que pythonhosted.org ne respectait pas le drapeau Requires-Python mais avec le même miroir, cela fonctionnait sur Debian Stretch avec Python 2.7.13 alors qu'il échouait sur Ubuntu Xenial avec Python 2.7.12, sinon des configurations système assez propres, même testé dans un environnement Docker. La version Python ne peut pas être la raison car le même problème a déjà été signalé avec Ubuntu Bionic et Python 2.7.17.

Donc, je suis perplexe où/à quel niveau le bogue doit être recherché, Python, virtualenv, pip, pythonhosted.org ou y a-t-il quelque chose au milieu ?
La solution de contournement est claire, mais ce serait formidable d'enquêter et de corriger la raison pour laquelle setuptools 45 est extrait en premier lieu.