Pip: "Sem distribuição correspondente" devido às etiquetas das rodas não corresponderem no pip 20.0

Também estamos tendo esse erro ao usar a versão 20.0.1 com nosso volante interno

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

O mesmo aqui com uma roda interna.

Não funciona:
pip install -U pip==20.0.1; pip install <wheel>
ERRO:não é uma roda com suporte nesta plataforma.

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

Parece que as tags de plataforma são o problema aqui: as tags 'any' estão funcionando, mas esta roda de especificação tem 'linux_x86_64'.

Observe que eu tenho:

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

O mesmo aqui.

19.3.1 funciona, mas 20.0.1 dá:
pip._internal.exceptions.InstallationError: pyenchant-2.0.0-py2.py3.cp27.cp32.cp33.cp34.cp35.cp36.pp27.pp33.pp35-none-win32.whl não é uma roda com suporte nesta plataforma.

Tags para meu pc: [('cp37', 'cp37m', 'win32'), ('cp37', 'nenhum', 'win32'), ('cp37', 'nenhum', 'qualquer'), (' cp3 ',' nenhum ',' qualquer '), (' cp36 ',' nenhum ',' qualquer '), (' cp35 ',' nenhum ',' qualquer '), (' cp34 ',' nenhum ',' qualquer '), (' cp33 ',' nenhum ',' qualquer '), (' cp32 ',' nenhum ',' qualquer '), (' cp31 ',' nenhum ',' qualquer '), (' cp30 ' , 'nenhum', 'qualquer'), ('py3', 'nenhum', 'win32'), ('py37', 'nenhum', 'qualquer'), ('py3', 'nenhum', 'qualquer' ), ('py36', 'nenhum', 'qualquer'), ('py35', 'nenhum', 'qualquer'), ('py34', 'nenhum', 'qualquer'), ('py33', ' none ',' any '), (' py32 ',' none ',' any '), (' py31 ',' none ',' any '), (' py30 ',' none ',' any ')]

Marcas para arquivo podem ser vistas em nome de arquivo.

Você poderia imprimir as diferenças entre pip debug -v no pip 20.0.1 e 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

`` `diff
-pip versão: pip 19.3.1 de c: sdkspython37-32libsite-packagespip (python 3.7)
+ versão pip: pip 20.0.1 de c: sdkspython37-32libsite-packagespip (python 3.7)
sys.version: 3.7.6 (tags / v3.7.6: 43364a7ae0, 18 de dezembro 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
sys.implementation:
nome: cpython
-A variável de configuração 'Py_DEBUG' não está definida, a tag Python ABI pode estar incorreta
-A variável de configuração 'WITH_PYMALLOC' não está definida, a tag Python ABI pode estar incorreta
-Tags compatíveis: 14
+ valor de configuração 'cert': global
+ REQUESTS_CA_BUNDLE: Nenhum
+ CURL_CA_BUNDLE: Nenhum
+ pip._vendor.certifi.where (): c: sdkspython37-32libsite-packagespip_vendorcertificacert.pem
+ Tags compatíveis: 19
cp37-cp37m-win32
+ cp37-abi3-win32
cp37-nenhum-win32
- py3-nenhum-win32
+ cp36-abi3-win32
+ cp35-abi3-win32
+ cp34-abi3-win32
+ cp33-abi3-win32
+ cp32-abi3-win32
+ py37-none-win32
cp37-nenhum-nenhum
- cp3-nenhum-nenhum
py37-nenhum-nenhum
py3-nenhum-nenhum
py36-nenhum-nenhum

Semelhante no Windows - a seção de tag da saída:

--- ".\\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 tem valores diferentes dos da versão pip usada internamente no pip 19. A principal diferença é a falta de {py3,cp3}-none-win_amd64 . Que não é uma tag padrão gerada por bdist_wheel AFAIK, então pelo menos o impacto será limitado às pessoas que definem tags personalizadas.

As especificações não dizem muito sobre quais tags personalizadas como essa são válidas, portanto, é indiscutivelmente na área de "comportamento indefinido". Embora isso não ajude as pessoas afetadas por isso, sugere que seria bom ser mais específico nos padrões.

Aliás, não tenho certeza do que mxnet-1.5.1.post0-py2.py3-none-manylinux1_x86_64.whl significa - as versões do MacOS do mxnet têm um conjunto ABI específico, por que o manylinux não compila? As compilações de manylinux do Numpy têm uma ABI, portanto, não parece ser um problema geral com o conjunto de ferramentas manylinux. As tags para pyenchant também parecem um pouco bizarras ...

as versões MacOS do mxnet têm um conjunto ABI específico, por que o manylinux não compila?

Verifiquei rapidamente o pacote Linux e parece que nenhuma das bibliotecas nativas ali se refere a símbolos Python. Parece que o MXNet usa ctypes para interoperar com o código nativo, portanto, não faz sentido não ter uma ABI.

Ter o mesmo problema ao instalar icc-rt (de intel-numpy) (2020.0.133) usando pip == 20.0.1

Verifiquei rapidamente o pacote Linux e parece que nenhuma das bibliotecas nativas ali se refere a símbolos Python. Parece que o MXNet usa ctypes para interoperar com o código nativo, portanto, não faz sentido não ter uma ABI.

ESTÁ BEM. Por que ele precisa de uma tag "manylinux" nesse caso, se está usando ctypes para tudo? Na verdade, não perca tempo com essa pergunta, não sou um especialista em Linux, então provavelmente não seguiria a resposta de qualquer maneira.

No mínimo, isso soa como um problema contra a biblioteca packaging . Independentemente do que o pip faz, se essas são tags válidas, elas devem ser suportadas em packaging.tags , e uma discussão geral sobre quais tags devem ser suportadas é provavelmente melhor do que aqui.

ESTÁ BEM. Por que ele precisa de uma tag "manylinux" nesse caso, se está usando ctypes para tudo? Na verdade, não perca tempo com essa pergunta, não sou um especialista em Linux, então provavelmente não seguiria a resposta de qualquer maneira.

Vou responder de qualquer maneira: a roda tem bibliotecas nativas do Linux, então a tag manylinux1 faz sentido.

Em https://github.com/pypa/pip/issues/7620#issuecomment -576743862 @tomasaschan relatou o que eu acho que é o mesmo problema para xgboost , que é enviado como xgboost-0.90-py2.py3-none-manylinux1_x86_64.whl . Ele também parece conter libs nativos, talvez para o JVM.

Obrigado @IRDonch . Eu fiz realmente seguir essa explicação 🙂 Faz sentido.

@jamadden: Concordo, parece o mesmo problema.

@jamadden O que posso fazer localmente para ajudá-lo a determinar se isso é o mesmo?

@tomasaschan Você pode colar aqui a saída 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 o problema

Este é um Dockerfile que reproduz nossa mensagem de erro:

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 Boa captura - parece que pode ser um bug direto em packaging.tags (reutilizando um iterador ao invés de recriá-lo a cada vez). Você poderia abrir um problema em https://github.com/pypa/packaging para isso - e se você pudesse fazer sua correção em um PR, seria ainda melhor!

Não tenho certeza se isso ajuda, mas estou enfrentando o mesmo problema ao tentar instalar dotnetcore2

Enfrentando o mesmo problema com freetype-py no macOS: https://github.com/rougier/freetype-py/issues/119 ("corrigido" fixando em 19.3.1)

Espere um lançamento de correção de bug para amanhã, supondo que eu me recupere da minha dor de cabeça atual até lá. :)

O mesmo problema com nossas rodas internas (pip 20.0.1), uma solução alternativa é usar pip <20 por enquanto. Esperançosamente, sua correção de hoje irá resolver o problema. Obrigado!

Okie, # 7643 deve consertar as coisas. Assim que for mesclado (e eu volto para o meu laptop), farei o lançamento do pip 20.0.2.

Se as pessoas quiserem dar uma olhada no # 7643 e confirmar que realmente corrige o problema para elas, isso seria ótimo! Para instalar isso, você pode fazer:

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

Use a reação 👍 neste comentário se você já experimentou o PR, e ele funciona para você. :)

Okie, então a correção agora está no mestre. Farei o lançamento daqui a pouco - siga o # 7531.

Lançado em 20.0.2 contendo a correção para isso.

Se você ainda estiver vendo algo semelhante, dê uma olhada em # 7629 (se você estiver no PyPy) ou registre um novo problema. :)

Isso agora funciona novamente com o pip 20.0.2 lançado há alguns minutos. Obrigado a todos pelo patch oportuno!

Obrigado, estamos prontos e funcionando novamente!

@pradyunsg Posso confirmar que meu repro do Docker acima foi corrigido em 20.0.2.

Ótimo trabalho nisso, muito obrigado (de todos nós)! ❤️

Há uma regressão

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

@afabiani você pode fornecer um traceback completo e instruções de como reproduzir, por favor? Em uma nova edição, pois parece não ter relação com o assunto desta edição.

Oh, vejo que você fez em # 7645

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

Obrigado! Esse é um problema não relacionado causado por um uso sem suporte de pip, e não um bug / regressão introduzido no pip 20.0.2. Vejo que @pfmoore respondeu com mais detalhes lá, então vamos discutir mais sobre esse assunto.

Corri para isso na noite de sexta-feira e cheguei ao trabalho esta manhã para encontrá-lo já consertado e lançado - obrigado a todos os envolvidos em fazer a correção acontecer tão rapidamente! : D

Ei! Esta correção (20.0.2) realmente não corrigiu meu problema. Alguém tem ideia do que está causando esse problema?

pip instalar artefatos-chaveiro
Procurando nos índices: https://pypi.org/simple, PRIVATE_PACKAGE_REFERENCE
Coletando artefatos-chaveiro
Baixando artifacts_keyring-0.2.9-py2.py3-none-any.whl (4,8 MB)
| ████████████████████████████████ | 4,8 MB 2,5 MB / s
Requisito já atendido: keyring> = 16.0 in /usr/local/lib/python3.7/site-packages (from artifacts-keyring) (21.1.0)
Requisito já atendido: solicitações> = 2.20.0 em /usr/local/lib/python3.7/site-packages (de artifacts-keyring) (2.22.0)
ERRO: Não foi possível encontrar uma versão que satisfaça o requisito dotnetcore2; sys_platform! = "win32" e python_version> = "3.0" (de artifacts-keyring) (de ver
sions: nenhum)
ERRO: Nenhuma distribuição correspondente encontrada para dotnetcore2; sys_platform! = "win32" e python_version> = "3.0" (do artifacts-keyring)

Se você ainda estiver vendo algo semelhante, dê uma olhada em # 7629 (se você estiver no PyPy) ou registre um novo problema. :)

Registre um novo problema.