isso é um problema debian

nota extra - substituir o pip do sistema por pip é sempre um ato de vandalismo do sistema, onde aquele que o inflige é responsável pela precipitação radioativa

Eu sugiro que você deve esperar por uma cópia apropriada do pacote apt do pip 10 do Debian - como @RonnyPfannschmidt diz, você não deve usar o pip para atualizar seus pacotes de sistema ...

Parece que o script Debian pip3 usa o interno do pip, então obter uma correção compatível com o pip10 é definitivamente com eles (e eu espero que eles aguardem o lançamento de seu pacote pip10 até que tenham isso classificado).

nota extra - substituir o pip do sistema por pip é sempre um ato de vandalismo do sistema, onde aquele que o inflige é responsável pela precipitação radioativa

Convença o pessoal do debian / ubuntu a não vender e então deixe apodrecer metade de seus pacotes, e esse seria um argumento válido.

Você pode usar o virtualenv ou venv para se isolar da instalação do pip do sistema.

Você não deve modificar os arquivos gerenciados pelo gerenciador de pacotes (aqui a instalação pip do sistema) - acho que eles não esperam que os usuários modifiquem coisas - provavelmente não é suportado pelo Debian. É provável que cause problemas como este.

O mesmo problema no Fedora também.

Talvez devesse haver um canal "beta" ou algum mecanismo semelhante para que as pessoas façam mais testes antes do lançamento, em vez de apenas despejar uma versão quebrada no pypi e fazer com que as compilações de todos explodam.

@ fake-name Foram feitos dois pré-lançamentos:

• 10.0.0b1 foi lançado em 31 de março
• 10.0.0b2 foi lançado em 2 de abril

@fake-name além disso, a sugestão geral para uso em todas as distros é - use um virtualenv, não vandalize o sistema e isso funciona - as pessoas apenas seguem a fonte e se perguntam quando as coisas quebram e culpam o pip

tem havido muitos testes manuais e automatizados com o virtualenvs que funciona

também em um virtualenv, pelo menos não deve haver nenhum comando debian made pip3 - então do que diabos você está falando sobre essa quebra no virtualenvs - forneça dados suficientes para realmente verificar em vez de reclamar sobre quebras sem fornecer os dados necessários para verificá-los

pip é dirigido por voluntários, não uma empresa com dezenas de funcionários

~ Excluído ~. estava confundindo isso com https://github.com/pypa/pip/issues/5220

Eu sou um derp.

Obrigado, não tinha percebido que substituir o pip do sistema era uma má ideia, mas faz sentido. No entanto, seria uma boa experiência do usuário se pip não reclamasse da atualização nesse caso. Isso seria possível? Eu acho que muitas pessoas (incluindo eu) simplesmente fariam qualquer coisa que "a coisa" lhes pedisse para fazer.

@fake-name, obrigado por acompanhar - é surpreendentemente comum não combinar o problema de detalhes quando um grande lançamento tem um impacto multifacetado e parte dele tenta arruinar seu dia

seria uma boa experiência do usuário se pip não reclamasse da atualização nesse caso

Os fornecedores de distribuição certamente poderiam corrigir o pip para remover esse aviso (ou melhor, substituí-lo por uma verificação semelhante nos pacotes do sistema) junto com os outros patches que fazem. Não tenho certeza de como o pip base pode detectar que está sendo executado a partir de um pacote de instalação do sistema sem cooperação da distribuição, mas se houver uma maneira de fazer isso, isso é algo que poderíamos considerar (mas esteja ciente de que, em minha experiência, obtemos como muito feedback negativo de obter tais heurísticas erradas como fazemos por não incluir as heurísticas de forma alguma ...)

Sempre prefira "python3 -m pip" em vez de pip3 "ou ainda melhor" / usr / bin / env python3 -m pip "é mais seguro e permite evitar esse problema com pip10

Resolvemos esse problema limpando o hash no bash:

$ hash -d pip

Ou no travessão (sh):

$ hash -r pip

Também enfrente esse problema ao construir imagens do docker.

@RonnyPfannschmidt diz que "substituir o pip do sistema por pip é sempre um ato de vandalismo do sistema onde quem o inflige é responsável pela precipitação", que tem 6 polegares para cima. Acho que este é um comentário especialmente obtuso, visto que instruí a fazê-lo pelo próprio pip:

_Você está usando o pip versão 8.1.1; no entanto, a versão 10.0.0 está disponível.
Você deve considerar a atualização por meio do comando 'pip install --upgrade pip'.

Se houver alguma validade nesse comentário, os criadores do pip devem remover esta mensagem e eu encorajaria @RonnyPfannschmidt a levantar uma questão nesse sentido e apresentar seu caso.

@qacollective - acho que o argumento aqui é que as distros pegaram o pip, o modificaram e reempacotaram em seus repositórios. Como tal, não é realmente culpa de Pypi que a mensagem ainda esteja lá.

A maior parte disso ocorre porque várias distros tentam muito, muito mesmo, empacotar tudo em seus próprios repositórios de pacotes. Principalmente, as coisas apodrecem.

Pessoalmente, pelo menos para python no ubuntu, gostaria que eles parassem. A versão de basicamente cada pacote python no apt varia de muito, muito antigo a fossilizado. Apt é basicamente inútil para python, IMHO.

FWIW, tendo a achar que a melhor opção é nunca instalar o pip da distro em primeiro lugar, mas instalá-lo manualmente via get-pip.py . Dessa forma, você não terá problemas com o gerenciador de pacotes da plataforma sabendo apenas sobre alguns dos pacotes Python.

Sempre use --user para evitar matar seu sistema

/usr/bin/env python3 -m pip intall --user --upgrade pip

Deve lidar com a maioria dos casos de bugs e resultar na instalação da versão correta do pip em ˜/.local/bin .

Posso confirmar que a solução de @standag está funcionando.

Um pouco de contexto: após a atualização (pip install -U pip) em um vanilla ubuntu 16.04 (AWS AMI), chega-se à seguinte situação:
$ PATH = ..: / usr / local / bin: ... : / usr / bin: ...
/ usr / bin / pip ainda é a versão antiga / 'oem' (quebrada)
/ usr / local / bin / pip é o novo script v10 (funciona bem quando invocado diretamente)

Mesmo que a versão apropriada do pip preceda a versão quebrada no PATH, o bash ainda se lembra da versão antiga, então quando você o invocar apenas como 'pip', você obterá a versão velha e quebrada em execução. hash-d pip ou hash -r resolve o problema.

Primeiro, algumas notas sobre o que aconteceu aqui no Debian / Ubuntu (e provavelmente mais algumas distros do Linux):

• pip não suporta o uso de seus componentes internos, importando-os. Mais sobre isso na documentação aqui .
• Debian (portanto, Ubuntu) não suporta a modificação de seus arquivos gerenciados pelo gerenciador de pacotes usando algo que, bem, não é o gerenciador de pacotes.

Esse problema é causado por, bem, ambos terem sido violados de alguma forma.

• O Debian usa os métodos internos do pip (que não funcionam mais devido a uma reorganização dos internos do pip). O Debian está assumindo aqui que a versão pip em seus repositórios é a que deve ser instalada.
• Executar pip install --upgrade pip , como root, sem quaisquer outros parâmetros, modifica os arquivos que deveriam ser gerenciados pelo apt, o que quebra o script do Debian.

Algumas dicas gerais sobre Linux:

• É um bom hábito usar --user sempre que estiver fora de um local.

  pip install --upgrade --user pip
  

• Nunca execute o pip com o sudo, a menos que saiba o que está fazendo.

Qual é a solução alternativa?

A solução de @standag é útil quando isso é causado pelo cache de executáveis ​​do bash.

hash -r pip # or hash -d pip

Se você modificou a instalação do pip do gerenciador de pacotes do sistema operacional (por exemplo, usando sudo pip ) e python -m pip ainda está funcionando, uma solução alternativa é desinstalar a versão instalada do pip e reinstalar a versão instalada do gerenciador de pacotes .

python -m pip uninstall pip  # this might need sudo
sudo apt install --reinstall python-pip

Se você não estiver no Debian / Ubuntu _and_ pip quebrou para você, tente executar:

python -m pip install --force-reinstall pip

Se o procedimento acima não resolver seus problemas, registre um novo problema.

[editado por @pradyunsg : torne-o mais relevante para vincular todos com problemas semelhantes a este comentário; atualize a sugestão para incluir a solução alternativa de desinstalação / reinstalação]

Que tal resolvê-lo fora do docker? Está quebrado em meu sistema normal e o comando hash não reconheceu pip.
thinkdigital@thinkdigital-HP-Spectre-x360-Convertible:~$ hash -d pip bash: hash: pip: not found

Eu encontrei pip3, versão 9.0.1 instalado em um virtualenv de um projeto e copiei para meu / usr / bin e ele funciona novamente. Aqui está o conteúdo do executável pip3 para aqueles que desejam consertá-lo por conta própria também.

# -*- coding: utf-8 -*-
import re
import sys

from pip import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

Tenho certeza de que tudo o que você precisa fazer é salvá-lo em um arquivo chamado pip3, torná-lo executável executando sudo chmod + x ./pip3, executar sudo apt remove python3-pip e copiá-lo para o diretório bin executando sudo cp ./pip3 / usr / bin.
Aqui está o arquivo raw para aqueles que desejam apenas fazer o download e movê-lo.
pip3.zip

Funciona para mim:
curl https://bootstrap.pypa.io/get-pip.py | sudo python

Sinto muito, mas gostaria de salientar que executar o código Python curl de algum site com acesso root é terrivelmente inseguro.

Concordo, e devo ressaltar que esta não é uma recomendação oficial do pip. Como já foi afirmado várias vezes, você deve usar o gerenciador de pacotes do sistema para atualizar ou de outra forma gerenciar a instalação do pip do sistema, não do get-pip ou mesmo do próprio pip via sudo.

Neste caso, a versão do gerenciador de pacotes do sistema não funciona. Até
após a purga e reinstalação.

Na quinta-feira, 19 de abril de 2018, 1h53, Paul Moore [email protected] escreveu:

Concordo, e devo ressaltar que este não é um pip oficial
recomendação. Como já foi dito várias vezes, você deve usar
o gerenciador de pacotes do sistema para atualizar ou de outra forma gerenciar o pip do sistema
instalação, não get-pip, ou até mesmo pip via sudo.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pypa/pip/issues/5221#issuecomment-382660881 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AV-Hfecz8l1NEyq3vsih0DpNP7QYdxuvks5tqFCdgaJpZM4TVEq6
.

Se reinstalar o pacote do sistema ainda não funcionar, verifique se você tem pip10 em algum lugar em / usr / local / e exclua a pasta inteira.

Substituir o de / usr / bin funcionou para mim, embora eu ACHE que seja
aquele que o gerenciador de pacotes do sistema estava instalando.

[ @pradyunsg cortou o conteúdo do e-mail]

@ThinkDigitalRepair O seguinte ajuda?

Em outros casos, você desejará passar --user ao instalar / atualizar pacotes. TBH, no Linux, é um bom hábito usar --user .

pip install --upgrade --user pip

OK. Obrigado. Eu estraguei tudo seguindo um tutorial do Jupyter Notebook de seu
site que diz a você para atualizar o pip diretamente. Copiar e colar sem
saber as consequências ataca novamente. :(

[ @pradyunsg cortou o conteúdo do e-mail]

Esperançosamente, @ThinkDigitalRepair pip 10 estará melhorando as coisas - está imprimindo mensagens de erro melhores em vez de um PermissionError longo quando isso acontece.

Encerrando este problema agora, pois não há nada acionável aqui do final do pip.

Para saber como corrigir / contornar esse problema, dê uma olhada em https://github.com/pypa/pip/issues/5221#issuecomment -382069604.

@pradyunsg em muitos casos, as soluções fornecidas nesse comentário não funcionarão. Em um Ubuntu 17.10 novo, execute pip install --upgrade pip : depois disso, o comando pip será quebrado e as soluções do comentário não o consertarão. E eles não deveriam!

Ter um sistema pip 9 instalado com um pip 10 instalado pelo usuário faz com que o script pip do sistema tente importar main () do usuário pip 10, com um caminho de importação incorreto. Hash -r ou -d não consertará isso porque o comando pip ainda executará o pip do sistema por padrão. E nem irá consertar atualizando o usuário pip, já que o pip do sistema ainda será 9, o usuário pip ainda será 10, então a importação continuará falhando.

A solução para esses casos deve ser desinstalar um dos dois pips.

• python -m pip uninstall pip --user , mantendo o pip do sistema, que é mais antigo

ou

• sudo apt remove python-pip e mantenha o pip instalado pelo usuário, que não será acessível executando pip no terminal por padrão. Você precisará executá-lo com python -m pip ou adicionar os caminhos para sua var de env PATH, etc.

Tudo isso se aplica a ambos, pip sob python 2 e 3.

Em todos os meus sistemas Ubuntu (16.04, 17.10. 18.04), tenho o pip do sistema para a versão antiga e o usuário está com o pip 10 e nunca vejo seu erro de importação.
Tem certeza de que não possui um pip do sistema corrompido?

@gsemet você provavelmente adicionou ~/.local/bin ao seu PATH env var (ou talvez usando um shell diferente e mais inteligente do que o bash padrão), então quando você executa pip ele usa o script pip 10 instalado pelo usuário, e não o script pip 9 instalado pelo sistema. No Ubuntu, isso não é assim por padrão. Isso pode ser feito, com certeza, e gostaria que fosse assim por padrão. Mas, por padrão, o comando pip chamará o pip instalado pelo sistema, mesmo se você tiver um instalado pelo usuário.

Como reproduzir isso em uma instalação nova do Ubuntu 17.10, incluindo a evidência de que os comandos no comentário 5221 falham em consertar, e o que propus conserta.

Instalação de ambos os pips (sistema e usuário), que quebra o comando pip:

vfisa<strong i="7">@vilos</strong>:~$ sudo apt install python-pip
(...)

vfisa<strong i="8">@vilos</strong>:~$ pip --version
pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

vfisa<strong i="9">@vilos</strong>:~$ which pip
/usr/bin/pip

vfisa<strong i="10">@vilos</strong>:~$ pip install pip --upgrade --user
Collecting pip
  Downloading https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl (1.3MB)
    100% |████████████████████████████████| 1.3MB 631kB/s 
Installing collected packages: pip
Successfully installed pip-10.0.1

vfisa<strong i="11">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="12">@vilos</strong>:~$ python -m pip --version
pip 10.0.1 from /home/vfisa/.local/lib/python2.7/site-packages/pip (python 2.7)

vfisa<strong i="13">@vilos</strong>:~$ which pip
/usr/bin/pip

Como você pode ver, o comando pip aponta para o pip do sistema por padrão, não para aquele instalado pelo usuário.

Comandos de comentários referenciados, evidências de que eles não corrigiram o problema:

vfisa<strong i="19">@vilos</strong>:~$ hash -r

vfisa<strong i="20">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="21">@vilos</strong>:~$ hash -d
hits    command
   1    /usr/bin/pip

vfisa<strong i="22">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="23">@vilos</strong>:~$ python -m pip install pip --force-reinstall --user
Collecting pip
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 10.0.1
    Uninstalling pip-10.0.1:
      Successfully uninstalled pip-10.0.1
Successfully installed pip-10.0.1

vfisa<strong i="24">@vilos</strong>:~$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

vfisa<strong i="25">@vilos</strong>:~$ which pip
/usr/bin/pip

Como você pode ver, enquanto os dois pips estiverem instalados e o comando pip apontar para o pip do sistema (comportamento padrão no Ubuntu), o problema persistirá.

Corrija a opção 1:

Remova o pip do sistema, mantenha o pip do usuário, que por padrão não é acessível por meio do comando pip (então você precisa usar python -m pip ).

vfisa<strong i="34">@vilos</strong>:~$ sudo apt remove python-pip
(...)

vfisa<strong i="35">@vilos</strong>:~$ pip
bash: /usr/bin/pip: No such file or directory

vfisa<strong i="36">@vilos</strong>:~$ python -m pip --version
pip 10.0.1 from /home/vfisa/.local/lib/python2.7/site-packages/pip (python 2.7)

Você poderia adicionar ~/.local/bin ao seu PATH env var, para poder usar o comando pip com o usuário pip.

Opção 2 de correção:

Remova o pip do usuário, mantenha o pip do sistema, que é mais antigo, mas por padrão tem um comando pip no caminho.

vfisa<strong i="45">@vilos</strong>:~$ python -m pip uninstall pip
Uninstalling pip-10.0.1:
  Would remove:
    /home/vfisa/.local/bin/pip
    /home/vfisa/.local/bin/pip2
    /home/vfisa/.local/bin/pip2.7
    /home/vfisa/.local/lib/python2.7/site-packages/pip-10.0.1.dist-info/*
    /home/vfisa/.local/lib/python2.7/site-packages/pip/*
Proceed (y/n)? y
  Successfully uninstalled pip-10.0.1
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

vfisa<strong i="46">@vilos</strong>:~$ pip --version
pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

@fisadev Claro, isso é necessário para oferecer suporte ao pacote 'pip install --user' instalável pelo usuário. Mas acho que deve ser dito aos usuários "se você quiser forçar a atualização para o pip 10 antes que o pacote debian / ubuntu seja atualizado, você precisa usar pip install --user --upgrade pip e garantir que $HOME/.local/bin esteja em seu caminho .É simples de fazer.

@gsemet : Concordo, os usuários devem ser informados sobre o requisito de caminho. Isso não é mencionado no comentário sendo referenciado por outros tópicos como a solução e, em um caso, a discussão foi bloqueada mesmo depois que um usuário disse que executou aqueles comandos e isso não resolveu o problema: /

@fisadev Muito obrigado. Corrigir a opção 1 realmente ajuda.

@RonnyPfannschmidt

substituir o pip do sistema por pip é sempre um ato de vandalismo do sistema em que aquele que o inflige é responsável pela precipitação radioativa

é um comentário de vandalismo mental. Como se a pessoa que está fazendo a atualização (ingênua) estivesse intencionalmente planejando danificar sua própria instalação ... Se fosse esse o caso, o próprio pip não deveria incomodar o usuário para atualizar de 9.0.1 para 10.0.1 a cada único comando pip executado. Eu próprio segui essa recomendação e acabei nesta confusão.

Felizmente:
sudo python -m pip install pip==9.0.1
foi um remédio bastante fácil.

Culpar a vítima não é resposta, no entanto.

Ei @ rod-app!

Se fosse esse o caso, o próprio pip não deveria incomodar o usuário para atualizar de 9.0.1 para 10.0.1 com cada comando pip executado.

Percebemos isso e trabalhamos com fornecedores de sistemas operacionais para evitar isso em versões futuras do pip. - # 5346.

Para resolver o problema que corri ...

sudo geany -i /usr/bin/pip

... e editado debian forneceu / usr / bin / pip para substituí-lo por ...

#!/bin/sh
# GENERATED BY CEFN
python -m pip "$@"

e o equivalente para / usr / bin / pip3 (observe que isso invoca python3).

#!/bin/sh
# GENERATED BY CEFN
python3 -m pip "$@"

... que traz de volta a funcionalidade completa do pip apesar da versão 10 instalada nos pacotes do meu site. Eu acho que isso vai durar exatamente o tempo que o debian levar para consertá-lo (ou quebrá-lo novamente) enviando um pacote python-pip atualizado. Por que eles não usaram o pacote principal, eu não sei.

Versão oficial

A versão do pip instalado em .local/bin/pip mostrada abaixo é um pouco mais sofisticada e inclui algumas substituições para remover as extensões -script, .py, .pyw e .exe dos argumentos passados, mas não sei o que isso faz ou por que eu preciso, então deixei como descrito acima para simplificar.

#!/usr/bin/python

# -*- coding: utf-8 -*-
import re
import sys

from pip._internal import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

Eu encontrei uma causa não relacionada para o problema do pip v10. Ao atualizar o pip usando um pip de sistema muito antigo (v1.5.6 no Debian Jessie, ou seja, oldstable) para o qual --system é o padrão, percebi que scripts incorretos foram instalados, por exemplo, /usr/local/bin/pip contendo from pip import main - que encontrei olhando os arquivos. Presumo que isso seja porque o pip mais antigo (ou talvez os pacotes de instalação que ele usa) instalam o arquivo .whl incorretamente.

python -m pip install --force-reinstall pip corrigiu isso.

5599 fornece informações e fornece um único local para buscar ajuda para resolver esse problema para os usuários finais.

A seção de comentários desse problema está aberta para os usuários discutirem problemas e soluções específicos. :)