Virtualenv: Setuptools v45.0.0 unterbricht Virtualenv auf Python 2

Ich bestätige, dass dies ein wichtiges Problem ist. In OpenStack sind die meisten Gates deswegen kaputt. Siehe: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011956.html

Danke für die Meldung, /me um eine halbe Stunde zu spät - ich dachte, virtualenv würde den modernen Resolver des Pip verwenden, aber das tut es anscheinend nicht.

Bereits in den Setuptools für einen anderen Downstream verfolgt https://github.com/pypa/setuptools/issues/1963

Ich bin mir nicht sicher, warum setuptools 45+ abgeholt wird, virtualenvs bootstrap sollte es 44 für setuptools behalten. 🤔

Hier ist der Traceback: http://paste.openstack.org/show/788301/

Legacy_resolve klingt nach etwas, das die neuen Regeln verwerfen würde.

Nein, falscher Weg zum Erkunden, raw pip ignoriert auch die Einschränkung der py-Version (obwohl sie als funktionierend beworben wird): http://paste.openstack.org/show/788302/

Ich schaue mir das mal an und veröffentliche morgen einen Fix. Wenn jemand Zeit hat, vorher eine PR zu machen, würde das helfen.

@yoctozepto kann Ihr Versagen nicht replizieren; Können Sie uns das vollständige Erstellungsprotokoll mit dreifacher Ausführlichkeit geben?

@gaborbernat Wenn es sich um das gleiche Problem wie bei pypa/pip#7586 handelt, kann dies ein Fehler in einem der PyPA-Spiegel sein, die @yoctozepto verwendet .

Anscheinend gibt einer von ihnen die python_requires Informationen nicht korrekt weiter.

Wenn dies der Fall ist, ist dies ein Fehler für diesen Spiegel; nichts mit uns zu tun 🤷‍♂

Folgendes hat für mich funktioniert, um dieses Problem zu lösen.

pip install --upgrade 'setuptools<45.0.0'

Ich arbeite mit einem Projekt, das noch Python 2.7 verwendet :(, und ich hatte das gleiche Problem.
Aber mit dem obigen Befehl (von ikrambabai) hat es wieder funktioniert !! :D
Vielen Dank!

Dies ist jedoch immer noch kritisch, wenn eine neue virtuelle Umgebung für Python 2.7 erstellt wird, da virtualenv setuptools-45.0.0 herunterladen würde und kein Upgrade (Downgrade über pip mit pip install --upgrade 'setuptools<45.0.0' ) es tatsächlich entfernen würde . Die einzige Lösung besteht darin, das Rad manuell herunterzuladen.

Dies ist jedoch immer noch kritisch, wenn eine neue virtuelle Umgebung für Python 2.7 erstellt wird, da virtualenv setuptools-45.0.0 herunterladen würde und kein Upgrade (Downgrade über pip mit pip install --upgrade 'setuptools<45.0.0' ) es tatsächlich entfernen würde . Die einzige Lösung besteht darin, das Rad manuell herunterzuladen.

Dies sollte nur passieren, wenn Sie sich hinter einem Indexserver befinden, der keine Python-Anforderungen propagiert ... daher würde ich empfehlen, den Indexserver zu reparieren.

@gaborbernat ist mir nicht bekannt. Gibt es eine Möglichkeit für mich das zu überprüfen?

Ich kann sehen, dass pythonhosted.org beim Herunterladen der Pakete beim Erstellen der virtualenv verwendet wird:

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

Übergeben Sie die Flags -v für pip install setuptools -vvv ?

Das funktioniert und die richtige Version ist installiert:

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

Das Problem tritt nur beim Erstellen der virtuellen Umgebung auf.

@ostefano Bei mir war es genauso. Ich habe dies umgangen, indem ich setuptools explizit installiert habe:

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

Wir hatten das gleiche Problem: https://github.com/mozilla-services/syncserver/issues/239
Zuerst dachte ich, es sei pythonhosted.org, das das Flag Requires-Python nicht respektiert, aber mit dem gleichen Spiegel funktioniert es unter Debian Stretch mit Python 2.7.13, während es unter Ubuntu Xenial mit Python 2.7.12 fehlschlägt, ansonsten ziemlich saubere System-Setups. sogar in einer Docker-Umgebung getestet. Die Python-Version kann nicht der Grund sein, da das gleiche Problem bereits mit Ubuntu Bionic und Python 2.7.17 gemeldet wurde.

Also bin ich ein bisschen ratlos wo/auf welcher Ebene der Bug gesucht werden muss, Python, virtualenv, pip, pythonhosted.org oder ist da was dazwischen?
Die Problemumgehung ist klar, aber es wäre großartig, den Grund zu untersuchen und zu beheben, warum setuptools 45 überhaupt gezogen wird.