Pip: "No hay distribución coincidente" debido a que las etiquetas de las ruedas no coinciden en pip 20.0

También estamos teniendo este error al usar la versión 20.0.1 con nuestra rueda interna

(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.

Usar pip install pip==19.3.1 funciona bien.

Lo mismo ocurre con una rueda interna.

No funciona:
pip install -U pip==20.0.1; pip install <wheel>
ERROR:no es una rueda compatible con esta plataforma.

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

Parece que las etiquetas de la plataforma son el problema aquí: las etiquetas 'any' están funcionando, pero esta rueda específica tiene 'linux_x86_64'.

Tenga en cuenta que tengo:

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')]

Igual que aquí.

19.3.1 funciona pero 20.0.1 da:
pip._internal.exceptions.InstallationError: pyenchant-2.0.0-py2.py3.cp27.cp32.cp33.cp34.cp35.cp36.pp27.pp33.pp35-none-win32.whl no es una rueda compatible en esta plataforma.

Etiquetas para mi PC: [('cp37', 'cp37m', 'win32'), ('cp37', 'none', 'win32'), ('cp37', 'none', 'any'), (' cp3 ',' ninguno ',' cualquiera '), (' cp36 ',' ninguno ',' cualquiera '), (' cp35 ',' ninguno ',' alguno '), (' cp34 ',' ninguno ',' any '), (' cp33 ',' none ',' any '), (' cp32 ',' none ',' any '), (' cp31 ',' none ',' any '), (' cp30 ' , 'ninguno', 'cualquiera'), ('py3', 'ninguno', 'win32'), ('py37', 'ninguno', 'cualquiera'), ('py3', 'ninguno', 'cualquiera' ), ('py36', 'none', 'any'), ('py35', 'none', 'any'), ('py34', 'none', 'any'), ('py33', ' none ',' any '), (' py32 ',' none ',' any '), (' py31 ',' none ',' any '), (' py30 ',' none ',' any ')]

Las etiquetas para el archivo se pueden ver en el nombre del archivo.

¿Podría imprimir las diferencias entre pip debug -v en pip 20.0.1 y pip 19.3.1?

--- /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

`` dif
-pip versión: pip 19.3.1 de c: sdkspython37-32libsite-packagespip (python 3.7)
+ versión de pip: pip 20.0.1 de c: sdkspython37-32libsite-packagespip (python 3.7)
sys.version: 3.7.6 (etiquetas / v3.7.6: 43364a7ae0, 18 de diciembre de 2019, 23:46:00) [MSC v.1916 de 32 bits (Intel)]
sys.executable: c: sdkspython37-32python.exe
sys.getdefaultencoding: utf-8
@@ -8,14 +8,21 @@ locale.getpreferredencoding: cp1252
sys.platform: win32
Implementación del sistema:
nombre: cpython
-La variable de configuración 'Py_DEBUG' no está configurada, la etiqueta ABI de Python puede ser incorrecta
-La variable de configuración 'WITH_PYMALLOC' no está configurada, la etiqueta ABI de Python puede ser incorrecta
-Etiquetas compatibles: 14
+ valor de configuración 'cert': global
+ REQUESTS_CA_BUNDLE: Ninguno
+ CURL_CA_BUNDLE: Ninguno
+ pip._vendor.certifi.where (): c: sdkspython37-32libsite-packagespip_vendorcertificacert.pem
+ Etiquetas compatibles: 19
cp37-cp37m-win32
+ cp37-abi3-win32
cp37-none-win32
- py3-ninguno-win32
+ cp36-abi3-win32
+ cp35-abi3-win32
+ cp34-abi3-win32
+ cp33-abi3-win32
+ cp32-abi3-win32
+ py37-ninguno-win32
cp37-none-any
- cp3-ninguno-ninguno
py37-ninguno-ninguno
py3-ninguno-ninguno
py36-ninguno-ninguno

Similar en Windows: la sección de etiquetas de la salida:

--- ".\\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

Parece que packaging.tags tiene valores diferentes a los de la versión pip utilizada internamente en pip 19. La principal diferencia es la falta de {py3,cp3}-none-win_amd64 . Lo cual no es una etiqueta estándar generada por bdist_wheel AFAIK, por lo que al menos el impacto se limitará a las personas que establezcan etiquetas personalizadas.

Las especificaciones no dicen mucho sobre qué etiquetas personalizadas como esta son válidas, por lo que podría decirse que esto se encuentra en el área de "comportamiento indefinido". Si bien eso no ayuda a las personas afectadas por esto, sí sugiere que sería bueno ser más específico en los estándares.

Por cierto, no estoy del todo seguro de lo mxnet-1.5.1.post0-py2.py3-none-manylinux1_x86_64.whl incluso medios - las versiones de MacOS mxnet tienen un conjunto específico de ABI, ¿por qué el manylinux construcción no? Las compilaciones de manylinux de Numpy tienen una ABI, por lo que no parece ser un problema general con la cadena de herramientas de manylinux. Las etiquetas para pyenchant también se ven un poco extrañas ...

las versiones de MacOS de mxnet tienen un conjunto ABI específico, ¿por qué la compilación manylinux no?

Revisé brevemente el paquete de Linux y parece que ninguna de las bibliotecas nativas allí se refiere a los símbolos de Python. Parece que MXNet usa ctypes para la interoperabilidad con código nativo, por lo que no tiene sentido tener una ABI.

Tiene el mismo problema al instalar icc-rt (de intel-numpy) (2020.0.133) usando pip == 20.0.1

Revisé brevemente el paquete de Linux y parece que ninguna de las bibliotecas nativas allí se refiere a los símbolos de Python. Parece que MXNet usa ctypes para la interoperabilidad con código nativo, por lo que no tiene sentido tener una ABI.

OKAY. ¿Por qué necesita una etiqueta "manylinux" en ese caso, si usa ctypes para todo? En realidad, no pierda tiempo en esa pregunta, no soy un experto en Linux, por lo que probablemente no seguiría la respuesta de todos modos.

Como mínimo, esto parece que debería plantearse como un problema contra la biblioteca packaging . Independientemente de lo que haga pip, si estas son etiquetas válidas, deberían ser compatibles con packaging.tags , y probablemente sea mejor tener una discusión general sobre qué etiquetas deberían ser compatibles allí que aquí.

OKAY. ¿Por qué necesita una etiqueta "manylinux" en ese caso, si usa ctypes para todo? En realidad, no pierda tiempo en esa pregunta, no soy un experto en Linux, por lo que probablemente no seguiría la respuesta de todos modos.

Responderé de todos modos: la rueda tiene bibliotecas nativas de Linux, por lo que la etiqueta manylinux1 tiene sentido.

En https://github.com/pypa/pip/issues/7620#issuecomment -576743862 @tomasaschan informó lo que creo que es el mismo problema para xgboost , que se envía como xgboost-0.90-py2.py3-none-manylinux1_x86_64.whl . También parece contener bibliotecas nativas, quizás para JVM.

@IRDonch Gracias. De hecho, seguí esa explicación 🙂 Tiene sentido.

@jamadden De acuerdo, parece el mismo problema.

@jamadden ¿Qué puedo hacer localmente para ayudarlo a determinar si esto es lo mismo?

@tomasaschan ¿Puedes pegar aquí la salida de pip debug -v ?

 λ 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:

parece resolver el problema

Aquí hay un Dockerfile que reproduce nuestro mensaje de error:

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 Buena captura: parece que puede ser un error directo en packaging.tags (reutilizar un iterador en lugar de volver a crearlo cada vez). ¿Podría abrir un problema contra https://github.com/pypa/packaging por esto, y si pudiera convertir su solución en un PR, sería aún mejor?

No estoy seguro de si esto ayuda, pero estoy enfrentando el mismo problema al intentar instalar dotnetcore2

Enfrentando el mismo problema con freetype-py en macOS: https://github.com/rougier/freetype-py/issues/119 ("arreglado" al fijar a 19.3.1)

Espero una versión de corrección de errores para este mañana, suponiendo que para entonces me recupere de mi dolor de cabeza actual. :)

El mismo problema con nuestras ruedas internas (pip 20.0.1), una solución es usar pip <20 por ahora. Es de esperar que su próxima corrección de hoy lo resuelva. ¡Gracias!

Okie, # 7643 debería arreglar las cosas. Una vez que se fusiona (y vuelvo a mi computadora portátil), haré el lanzamiento de pip 20.0.2.

Si la gente quiere probar el número 7643 y confirmar que realmente soluciona el problema, ¡sería genial! Para instalar eso, puede hacer:

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

Utilice la reacción 👍 en este comentario si ha probado las relaciones públicas y le funciona. :)

Okie, la solución ahora está en master. Haré el lanzamiento en un momento, por favor siga el n.

Lanzado 20.0.2 que contiene la solución para esto.

Si sigue viendo algo similar, eche un vistazo al # 7629 (si está en PyPy) o presente un nuevo problema. :)

Esto ahora funciona de nuevo con pip 20.0.2 lanzado hace unos minutos. ¡Gracias a todos por el parche oportuno!

Gracias, ¡estamos en funcionamiento de nuevo!

@pradyunsg Puedo confirmar que mi reproducción de Docker anterior está corregida en 20.0.2.

¡Gran trabajo en esto, muchas gracias (de todos nosotros)! ❤️

Hay una regresión

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

@afabiani, ¿ puede proporcionar un

Oh, veo que lo hiciste en el # 7645

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

¡Gracias! Ese es un problema no relacionado causado por un uso no compatible de pip, y no un error / regresión introducido en pip 20.0.2. Veo que @pfmoore ha respondido con más detalle allí, así que analicemos más ese tema.

Me encontré con esto a última hora del viernes y llegué al trabajo esta mañana para encontrar que ya estaba arreglado y liberado.¡Gracias a todos los involucrados en hacer que la solución sucediera tan rápido! :RE

¡Oye! Esta solución (20.0.2) en realidad no solucionó mi problema. ¿Alguien tiene idea de qué está causando este problema?

pip instalar artefactos-llavero
Buscando en índices: https://pypi.org/simple, PRIVATE_PACKAGE_REFERENCE
Colección de artefactos-llavero
Descargando artifacts_keyring-0.2.9-py2.py3-none-any.whl (4.8 MB)
| ██████████████████████████████ | 4,8 MB 2,5 MB / s
Requisito ya satisfecho: llavero> = 16.0 en /usr/local/lib/python3.7/site-packages (de artifacts-keyring) (21.1.0)
Requisito ya satisfecho: solicitudes> = 2.20.0 en /usr/local/lib/python3.7/site-packages (de artifacts-keyring) (2.22.0)
ERROR: No se pudo encontrar una versión que satisfaga el requisito dotnetcore2; sys_platform! = "win32" y python_version> = "3.0" (de artifacts-keyring) (de ver
siones: ninguna)
ERROR: No se encontró una distribución coincidente para dotnetcore2; sys_platform! = "win32" y python_version> = "3.0" (de artifacts-keyring)

Si sigue viendo algo similar, eche un vistazo al # 7629 (si está en PyPy) o presente un nuevo problema. :)

Presentar un nuevo problema.