Pip: "Keine übereinstimmende Verteilung" aufgrund von nicht übereinstimmenden Rad-Tags in Pip 20.0

Wir haben diesen Fehler auch bei Verwendung der Version 20.0.1 mit unserem hauseigenen Rad

(venv) C:\depot\bitbucket\mytests\tests_pti>pip -vvv install C:\Users\otrejoso\Downloads\pti-2.0.510-py3-none-win_amd64.whl
Non-user install because user site-packages disabled
Created temporary directory: C:\Users\otrejoso\AppData\Local\Temp\pip-ephem-wheel-cache-wquw3si6
Created temporary directory: C:\Users\otrejoso\AppData\Local\Temp\pip-req-tracker-ik56de2r
Initialized build tracking at C:\Users\otrejoso\AppData\Local\Temp\pip-req-tracker-ik56de2r
Created build tracker: C:\Users\otrejoso\AppData\Local\Temp\pip-req-tracker-ik56de2r
Entered build tracker: C:\Users\otrejoso\AppData\Local\Temp\pip-req-tracker-ik56de2r
Created temporary directory: C:\Users\otrejoso\AppData\Local\Temp\pip-install-vb0u5yy4
Cleaning up...
Removed build tracker: 'C:\\Users\\otrejoso\\AppData\\Local\\Temp\\pip-req-tracker-ik56de2r'
ERROR: pti-2.0.510-py3-none-win_amd64.whl is not a supported wheel on this platform.
Exception information:
....
pip._internal.exceptions.InstallationError: pti-2.0.510-py3-none-win_amd64.whl is not a supported wheel on this platform.

Die Verwendung von pip install pip==19.3.1 funktioniert einwandfrei.

Gleiches hier mit einem hauseigenen Rad.

Funktioniert nicht:
pip install -U pip==20.0.1; pip install <wheel>
ERROR:ist kein unterstütztes Rad auf dieser Plattform.

Werke:
pip install -U pip==19.3.1; pip install <wheel>

Scheint, dass die Plattform-Tags hier das Problem sind: Tags 'any' funktionieren, aber dieses angegebene Rad hat 'linux_x86_64'.

Beachten Sie, dass ich habe:

uname -a
Linux <propretiery> 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

 python -c "import wheel.pep425tags as w; print(w.get_supported())"
[('cp27', 'cp27mu', 'linux_x86_64'), ('cp27', 'none', 'linux_x86_64'), ('cp27', 'none', 'any'), ('cp2', 'none', 'any'), ('cp26', 'none', 'any'), ('cp25', 'none', 'any'), ('cp24', 'none', 'any'), ('cp23', 'none', 'any'), ('cp22', 'none', 'any'), ('cp21', 'none', 'any'), ('cp20', 'none', 'any'), ('py2', 'none', 'linux_x86_64'), ('py27', 'none', 'any'), ('py2', 'none', 'any'), ('py26', 'none', 'any'), ('py25', 'none', 'any'), ('py24', 'none', 'any'), ('py23', 'none', 'any'), ('py22', 'none', 'any'), ('py21', 'none', 'any'), ('py20', 'none', 'any')]

Hier gilt das gleiche.

19.3.1 funktioniert, aber 20.0.1 gibt:
pip._internal.exceptions.InstallationError: pyenchant-2.0.0-py2.py3.cp27.cp32.cp33.cp34.cp35.cp36.pp27.pp33.pp35-none-win32.whl ist auf dieser Plattform kein unterstütztes Rad.

Tags für meinen PC: [('cp37', 'cp37m', 'win32'), ('cp37', 'none', 'win32'), ('cp37', 'none', 'any'), (' cp3 ',' none ',' any '), (' cp36 ',' none ',' any '), (' cp35 ',' none ',' any '), (' cp34 ',' none ',' any '), (' cp33 ',' none ',' any '), (' cp32 ',' none ',' any '), (' cp31 ',' none ',' any '), (' cp30 ') , 'none', 'any'), ('py3', 'none', 'win32'), ('py37', 'none', 'any'), ('py3', 'none', 'any' ), ('py36', 'none', 'any'), ('py35', 'none', 'any'), ('py34', 'none', 'any'), ('py33', ' none ',' any '), (' py32 ',' none ',' any '), (' py31 ',' none ',' any '), (' py30 ',' none ',' any ')]

Tags für die Datei werden im Dateinamen angezeigt.

Könnten Sie die Unterschiede zwischen pip debug -v in Pip 20.0.1 und Pip 19.3.1 drucken?

--- /tmp/old.txt    2020-01-21 17:22:10.221211433 +0300
+++ /tmp/new.txt    2020-01-21 17:22:30.725552363 +0300
@@ -1,4 +1,4 @@
-pip version: pip 19.3.1 from /tmp/venv/lib/python3.6/site-packages/pip (python 3.6)
+pip version: pip 20.0.1 from /tmp/venv/lib/python3.6/site-packages/pip (python 3.6)
 sys.version: 3.6.9 (default, Nov  7 2019, 10:44:02) 
 [GCC 8.3.0]
 sys.executable: /tmp/venv/bin/python3
@@ -8,7 +8,11 @@
 sys.platform: linux
 sys.implementation:
   name: cpython
-Compatible tags: 42
+'cert' config value: global
+REQUESTS_CA_BUNDLE: None
+CURL_CA_BUNDLE: None
+pip._vendor.certifi.where(): /tmp/venv/lib/python3.6/site-packages/pip/_vendor/certifi/cacert.pem
+Compatible tags: 41
   cp36-cp36m-manylinux2014_x86_64
   cp36-cp36m-manylinux2010_x86_64
   cp36-cp36m-manylinux1_x86_64
@@ -37,12 +41,11 @@
   cp32-abi3-manylinux2010_x86_64
   cp32-abi3-manylinux1_x86_64
   cp32-abi3-linux_x86_64
-  py3-none-manylinux2014_x86_64
-  py3-none-manylinux2010_x86_64
-  py3-none-manylinux1_x86_64
-  py3-none-linux_x86_64
+  py36-none-manylinux2014_x86_64
+  py36-none-manylinux2010_x86_64
+  py36-none-manylinux1_x86_64
+  py36-none-linux_x86_64
   cp36-none-any
-  cp3-none-any
   py36-none-any
   py3-none-any
   py35-none-any

`` `diff
-pip Version: pip 19.3.1 von c: sdkspython37-32libsite-packagespip (Python 3.7)
+ pip version: pip 20.0.1 von c: sdkspython37-32libsite-packagespip (python 3.7)
sys.version: 3.7.6 (tags / v3.7.6: 43364a7ae0, 18. Dezember 2019, 23:46:00) [MSC v.1916 32-Bit (Intel)]
sys.executable: c: sdkspython37-32python.exe
sys.getdefaultencoding: utf-8
@@ -8,14 +8,21 @@ locale.getpreferredencoding: cp1252
sys.platform: win32
sys.implementation:
Name: cpython
-Config-Variable 'Py_DEBUG' ist nicht gesetzt, Python-ABI-Tag ist möglicherweise falsch
-Config-Variable 'WITH_PYMALLOC' ist nicht gesetzt, Python-ABI-Tag ist möglicherweise falsch
-Kompatible Tags: 14
+ 'cert' Konfigurationswert: global
+ REQUESTS_CA_BUNDLE: Keine
+ CURL_CA_BUNDLE: Keine
+ pip._vendor.certifi.where (): c: sdkspython37-32libsite-packagespip_vendorcertificacert.pem
+ Kompatible Tags: 19
cp37-cp37m-win32
+ cp37-abi3-win32
cp37-none-win32
- py3-none-win32
+ cp36-abi3-win32
+ cp35-abi3-win32
+ cp34-abi3-win32
+ cp33-abi3-win32
+ cp32-abi3-win32
+ py37-none-win32
cp37-none-any
- cp3-none-any
py37-none-any
py3-none-any
py36-none-any

Ähnlich unter Windows - der Tag-Abschnitt der Ausgabe:

--- ".\\pip19.txt"      2020-01-21 14:30:16 +0000
+++ ".\\pip20.txt"      2020-01-21 14:26:54 +0000
@@ -1,9 +1,15 @@
-Compatible tags: 15
+Compatible tags: 21
   cp38-cp38-win_amd64
+  cp38-abi3-win_amd64
   cp38-none-win_amd64
-  py3-none-win_amd64
+  cp37-abi3-win_amd64
+  cp36-abi3-win_amd64
+  cp35-abi3-win_amd64
+  cp34-abi3-win_amd64
+  cp33-abi3-win_amd64
+  cp32-abi3-win_amd64
+  py38-none-win_amd64
   cp38-none-any
-  cp3-none-any
   py38-none-any
   py3-none-any
   py37-none-any

Es sieht so aus, als ob packaging.tags andere Werte hat als die Version pip, die intern in pip 19 verwendet wird. Der Hauptunterschied ist das Fehlen von {py3,cp3}-none-win_amd64 . Dies ist kein Standard-Tag, das von bdist_wheel AFAIK generiert wird. Daher ist die Auswirkung zumindest auf Personen beschränkt, die benutzerdefinierte Tags festlegen.

Die Spezifikationen sagen nicht viel darüber aus, welche benutzerdefinierten Tags wie diese gültig sind, daher liegt dies wohl im Bereich "undefiniertes Verhalten". Dies hilft den Betroffenen zwar nicht, deutet jedoch darauf hin, dass es gut wäre, die Standards genauer zu definieren.

Übrigens bin ich mir nicht ganz sicher, was mxnet-1.5.1.post0-py2.py3-none-manylinux1_x86_64.whl überhaupt bedeutet - die MacOS-Versionen von mxnet haben einen bestimmten ABI-Satz, warum baut der manylinux nicht? Numpys manylinux-Builds haben einen ABI, daher scheint es kein allgemeines Problem mit der manylinux-Toolchain zu sein. Die Tags für pyenchant sehen auch etwas bizarr aus ...

Die MacOS-Versionen von mxnet haben einen bestimmten ABI-Satz. Warum baut der manylinux nicht?

Ich habe das Linux-Paket kurz überprüft, und es scheint, dass keine der nativen Bibliotheken dort auf Python-Symbole verweist. Es sieht so aus, als würde MXNet ctypes für die Interaktion mit nativem Code verwenden, daher ist es sinnvoll, keinen ABI zu haben.

Haben Sie das gleiche Problem bei der Installation von icc-rt (von Intel-Numpy) (2020.0.133) mit pip == 20.0.1

Ich habe das Linux-Paket kurz überprüft, und es scheint, dass keine der nativen Bibliotheken dort auf Python-Symbole verweist. Es sieht so aus, als ob MXNet ctypes für die Interop mit nativem Code verwendet, daher ist es sinnvoll, keinen ABI zu haben.

IN ORDNUNG. Warum braucht es in diesem Fall ein "manylinux" -Tag, wenn es für alles ctypes verwendet? Verbringen Sie keine Zeit mit dieser Frage, ich bin kein Linux-Experte, daher würde ich der Antwort wahrscheinlich sowieso nicht folgen.

Zumindest klingt dies so, als sollte es als Problem für die packaging -Bibliothek angesprochen werden. Unabhängig davon, was pip tut, wenn dies gültige Tags sind, sollten sie in packaging.tags , und eine allgemeine Diskussion darüber, welche Tags unterstützt werden sollten, ist dort wahrscheinlich besser als hier.

IN ORDNUNG. Warum braucht es in diesem Fall ein "manylinux" -Tag, wenn es für alles ctypes verwendet? Verbringen Sie keine Zeit mit dieser Frage, ich bin kein Linux-Experte, daher würde ich der Antwort wahrscheinlich sowieso nicht folgen.

Ich werde trotzdem antworten: Das Rad enthält native Linux-Bibliotheken, daher ist das manylinux1 -Tag sinnvoll.

In https://github.com/pypa/pip/issues/7620#issuecomment -576743862 @tomasaschan berichtete, was meiner Meinung nach dasselbe Problem für xgboost , das als xgboost-0.90-py2.py3-none-manylinux1_x86_64.whl geliefert wird . Es scheint auch native Bibliotheken zu enthalten, vielleicht für die JVM.

@ IRDonch Danke. Ich habe diese Erklärung tatsächlich befolgt. Akes Sinnvoll.

@ Jamadden Einverstanden, das sieht aus wie das gleiche Problem.

@jamadden Was kann ich vor Ort tun, um festzustellen, ob dies dasselbe ist?

@tomasaschan Kannst du hier die Ausgabe von pip debug -v einfügen?

 λ diff pip19.log pip20.log 
1c1
- pip version: pip 19.3.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)
---
+ pip version: pip 20.0.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)
11c11,15
- Compatible tags: 42
---
+ 'cert' config value: global
+ REQUESTS_CA_BUNDLE: None
+ CURL_CA_BUNDLE: None
+ pip._vendor.certifi.where(): /usr/local/lib/python3.6/dist-packages/pip/_vendor/certifi/cacert.pem
+ Compatible tags: 41
40,43c44,47
-   py3-none-manylinux2014_x86_64
-   py3-none-manylinux2010_x86_64
-   py3-none-manylinux1_x86_64
-   py3-none-linux_x86_64
---
+   py36-none-manylinux2014_x86_64
+   py36-none-manylinux2010_x86_64
+   py36-none-manylinux1_x86_64
+   py36-none-linux_x86_64
45d48
-   cp3-none-any

 λ cat pip19.log 
pip version: pip 19.3.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)
sys.version: 3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0]
sys.executable: /usr/bin/python
sys.getdefaultencoding: utf-8
sys.getfilesystemencoding: utf-8
locale.getpreferredencoding: UTF-8
sys.platform: linux
sys.implementation:
  name: cpython
Compatible tags: 42
  cp36-cp36m-manylinux2014_x86_64
  cp36-cp36m-manylinux2010_x86_64
  cp36-cp36m-manylinux1_x86_64
  cp36-cp36m-linux_x86_64
  cp36-abi3-manylinux2014_x86_64
  cp36-abi3-manylinux2010_x86_64
  cp36-abi3-manylinux1_x86_64
  cp36-abi3-linux_x86_64
  cp36-none-manylinux2014_x86_64
  cp36-none-manylinux2010_x86_64
  cp36-none-manylinux1_x86_64
  cp36-none-linux_x86_64
  cp35-abi3-manylinux2014_x86_64
  cp35-abi3-manylinux2010_x86_64
  cp35-abi3-manylinux1_x86_64
  cp35-abi3-linux_x86_64
  cp34-abi3-manylinux2014_x86_64
  cp34-abi3-manylinux2010_x86_64
  cp34-abi3-manylinux1_x86_64
  cp34-abi3-linux_x86_64
  cp33-abi3-manylinux2014_x86_64
  cp33-abi3-manylinux2010_x86_64
  cp33-abi3-manylinux1_x86_64
  cp33-abi3-linux_x86_64
  cp32-abi3-manylinux2014_x86_64
  cp32-abi3-manylinux2010_x86_64
  cp32-abi3-manylinux1_x86_64
  cp32-abi3-linux_x86_64
  py3-none-manylinux2014_x86_64
  py3-none-manylinux2010_x86_64
  py3-none-manylinux1_x86_64
  py3-none-linux_x86_64
  cp36-none-any
  cp3-none-any
  py36-none-any
  py3-none-any
  py35-none-any
  py34-none-any
  py33-none-any
  py32-none-any
  py31-none-any
  py30-none-any

 λ cat pip20.log 
pip version: pip 20.0.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)
sys.version: 3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0]
sys.executable: /usr/bin/python
sys.getdefaultencoding: utf-8
sys.getfilesystemencoding: utf-8
locale.getpreferredencoding: UTF-8
sys.platform: linux
sys.implementation:
  name: cpython
'cert' config value: global
REQUESTS_CA_BUNDLE: None
CURL_CA_BUNDLE: None
pip._vendor.certifi.where(): /usr/local/lib/python3.6/dist-packages/pip/_vendor/certifi/cacert.pem
Compatible tags: 41
  cp36-cp36m-manylinux2014_x86_64
  cp36-cp36m-manylinux2010_x86_64
  cp36-cp36m-manylinux1_x86_64
  cp36-cp36m-linux_x86_64
  cp36-abi3-manylinux2014_x86_64
  cp36-abi3-manylinux2010_x86_64
  cp36-abi3-manylinux1_x86_64
  cp36-abi3-linux_x86_64
  cp36-none-manylinux2014_x86_64
  cp36-none-manylinux2010_x86_64
  cp36-none-manylinux1_x86_64
  cp36-none-linux_x86_64
  cp35-abi3-manylinux2014_x86_64
  cp35-abi3-manylinux2010_x86_64
  cp35-abi3-manylinux1_x86_64
  cp35-abi3-linux_x86_64
  cp34-abi3-manylinux2014_x86_64
  cp34-abi3-manylinux2010_x86_64
  cp34-abi3-manylinux1_x86_64
  cp34-abi3-linux_x86_64
  cp33-abi3-manylinux2014_x86_64
  cp33-abi3-manylinux2010_x86_64
  cp33-abi3-manylinux1_x86_64
  cp33-abi3-linux_x86_64
  cp32-abi3-manylinux2014_x86_64
  cp32-abi3-manylinux2010_x86_64
  cp32-abi3-manylinux1_x86_64
  cp32-abi3-linux_x86_64
  py36-none-manylinux2014_x86_64
  py36-none-manylinux2010_x86_64
  py36-none-manylinux1_x86_64
  py36-none-linux_x86_64
  cp36-none-any
  py36-none-any
  py3-none-any
  py35-none-any
  py34-none-any
  py33-none-any
  py32-none-any
  py31-none-any
  py30-none-any

pip/_vendor/packaging/tags.py
332c332
-         platforms = _platform_tags
---
+         platforms = _platform_tags()
334c334
-         for platform_ in platforms():
---
+         for platform_ in platforms:

scheint das Problem zu lösen

Hier ist eine Docker-Datei, die unsere Fehlermeldung wiedergibt:

FROM ubuntu:bionic-20190912.1

RUN set -ex \
  && apt-get update \
  && apt-get install -y --no-install-recommends \
  ca-certificates \
  python3 python3-dev python3-pip

RUN pip3 install --upgrade pip==20.0.1 setuptools

RUN echo "xgboost==0.81" >> requirements.txt

RUN pip3 install -r requirements.txt

@jeroendecroos Guter Fang - das sieht so aus, als wäre es ein packaging.tags (einen Iterator erneut verwenden, anstatt ihn jedes Mal neu zu erstellen). Könnten Sie dafür ein Problem gegen https://github.com/pypa/packaging eröffnen - und wenn Sie Ihre Lösung in eine PR verwandeln könnten, wäre das sogar noch besser!

Ich bin mir nicht sicher, ob dies hilft, aber ich habe das gleiche Problem beim Versuch, dotnetcore2 zu installieren

Das gleiche Problem mit freetype-py unter macOS: https://github.com/rougier/freetype-py/issues/119 ("behoben" durch Fixieren auf 19.3.1)

Erwarten Sie morgen eine Bugfix-Version, vorausgesetzt, ich habe mich bis dahin von meinen aktuellen Kopfschmerzen erholt. :) :)

Das gleiche Problem mit unseren hauseigenen Rädern (Pip 20.0.1). Eine Problemumgehung besteht darin, vorerst Pip <20 zu verwenden. Hoffentlich wird Ihr heutiger heutiger Fix das Problem beheben. Vielen Dank!

Okie, # 7643 sollte die Dinge reparieren. Sobald das zusammengeführt ist (und ich zurück zu meinem Laptop komme), werde ich die Veröffentlichung von Pip 20.0.2 machen.

Wenn die Leute # 7643 für eine Spritztour nehmen und bestätigen möchten, dass dies tatsächlich das Problem für sie behebt, wäre das großartig! Um das zu installieren, können Sie Folgendes tun:

pip install https://github.com/pypa/pip/archive/1cf779c1ea88053c690686571d67826f11463232.zip

Bitte verwenden Sie die 👍-Reaktion auf diesen Kommentar, wenn Sie die PR ausprobiert haben und sie für Sie funktioniert. :) :)

Okie, das Update ist jetzt im Master. Ich werde die Veröffentlichung in Kürze machen - bitte folgen Sie # 7531.

Veröffentlicht 20.0.2 mit dem Fix dafür.

Wenn Sie immer noch etwas Ähnliches sehen, schauen Sie sich bitte # 7629 an (wenn Sie auf PyPy sind) oder reichen Sie eine neue Ausgabe ein. :) :)

Dies funktioniert jetzt wieder mit Pip 20.0.2, das vor einigen Minuten veröffentlicht wurde. Vielen Dank für den rechtzeitigen Patch!

Danke, wir sind wieder am Laufen!

@pradyunsg Ich kann bestätigen, dass mein Docker-Repro oben in 20.0.2 behoben ist.

Tolle Arbeit daran, vielen Dank (von uns allen)! ❤️

Es gibt eine Regression

ModuleNotFoundError: No module named 'pip._internal.download'

@afabiani können Sie bitte einen vollständigen Traceback und Anweisungen zur Reproduktion bereitstellen? In einer neuen Ausgabe, da dies nicht mit dem Thema dieser Ausgabe zu tun zu haben scheint.

Oh, ich sehe, du hast es bei # 7645 getan

@pfmoore https://github.com/pypa/pip/issues/7645

Vielen Dank! Dies ist ein nicht verwandtes Problem, das durch eine nicht unterstützte Verwendung von pip verursacht wird, und nicht durch einen in pip 20.0.2 eingeführten Fehler / eine Regression. Ich sehe, dass @pfmoore dort ausführlicher

Ich bin am späten Freitag darauf gestoßen und bin heute Morgen zur Arbeit gekommen, um festzustellen, dass es bereits repariert und freigegeben wurde. Vielen Dank an alle, die daran beteiligt waren, dass das Problem so schnell behoben wurde! : D.

Hallo! Dieser Fix (20.0.2) hat mein Problem nicht behoben. Hat jemand eine Ahnung, was dieses Problem verursacht?

Pip installieren Artefakte-Schlüsselring
In Indizes suchen: https://pypi.org/simple, PRIVATE_PACKAGE_REFERENCE
Artefakt-Schlüsselbund sammeln
Herunterladen von artefakten_keyring-0.2.9-py2.py3-none-any.whl (4,8 MB)
| ████████████████████████████████ | 4,8 MB 2,5 MB / s
Voraussetzung bereits erfüllt: Schlüsselring> = 16.0 in /usr/local/lib/python3.7/site-packages (aus Artefakt-Schlüsselring) (21.1.0)
Voraussetzung bereits erfüllt: Anfragen> = 2.20.0 in /usr/local/lib/python3.7/site-packages (vom Artefakt-Schlüsselring) (2.22.0)
FEHLER: Es konnte keine Version gefunden werden, die die Anforderung dotnetcore2 erfüllt. sys_platform! = "win32" und python_version> = "3.0" (vom Artefakt-Schlüsselring) (von ver
sionen: keine)
FEHLER: Für dotnetcore2 wurde keine übereinstimmende Verteilung gefunden. sys_platform! = "win32" und python_version> = "3.0" (vom Artefakt-Schlüsselring)

Wenn Sie immer noch etwas Ähnliches sehen, schauen Sie sich bitte # 7629 an (wenn Sie auf PyPy sind) oder reichen Sie eine neue Ausgabe ein. :) :)

Bitte reichen Sie eine neue Ausgabe ein.