Oi @KleinerNull!

Não tenho ideia se isso tem algo a ver com a atualização em si ou com o pyenv como ambiente.

Eu acho que isso é uma questão de meio ambiente. Eu sugiro que você abra um problema em pyenv, pois acho que as pessoas estariam em uma posição melhor para comentar sobre isso / corrigi-lo.

@pradyunsg

Eu abri um problema no repositório pyenv.

Estamos sofrendo com isso também, quebrou nosso pipeline. Operação sendo executada:

 11 #upgrade pip and install uwsgi
 12 pip install --user --upgrade pip
 13 pip install uwsgi

Ubuntu 16.04
Python3.6

Estamos enfrentando o mesmo problema.

// in host
$ docker pull ubuntu:xenial
$ docker run --name pip-test --rm -it ubuntu:xenial bash

// in container
# apt update
# apt install -y python-dev python-pip
# pip install --upgrade pip
Collecting pip
  Downloading pip-10.0.0-py2.py3-none-any.whl (1.3MB)
    100% |################################| 1.3MB 865kB/s 
Installing collected packages: pip
  Found existing installation: pip 8.1.1
    Not uninstalling pip at /usr/lib/python2.7/dist-packages, outside environment /usr
Successfully installed pip-10.0.0
# pip install requests
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

O mesmo aqui .. Exatamente a mesma saída que @HayaoSuzuki e não usamos pyenv

Se você está recebendo isso fora do pyenv, suspeito que seja mais provável que esteja relacionado ao # 5221

Só para mencionar que pip install --user --upgrade pip no Ubuntu 16.04 também quebra.

Curiosamente fácil de instalar o pip instala 10.0.0, mas não exibe o problema
```
// no hospedeiro
$ docker puxa ubuntu:xenial
$ docker run --name pip-test --rm -it ubuntu:xenial bash

// no recipiente

atualização apt

apt install -y python-setuptools

pip easy_install

Instalado /usr/local/lib/python2.7/dist-packages/pip-10.0.0-py2.7.egg
Processando dependências para pip
Dependências de processamento concluídas para pip

solicitações de instalação do pip

Coletando solicitações
Baixando requests-2.18.4-py2.py3-none-any.whl (88kB)
100% |###############################| 92kB 2.9MB/s
Coletando certificados>=2017.4.17 (de solicitações)
Baixando certifi-2018.1.18-py2.py3-none-any.whl (151kB)
100% |###############################| 153 KB 4,4 MB/s
Coletando chardet<3.1.0,>=3.0.2 (de solicitações)
Baixando chardet-3.0.4-py2.py3-none-any.whl (133kB)
100% |###############################| 143 KB 4,5 MB/s
Coletando idna<2.7,>=2.5 (de solicitações)
Baixando idna-2.6-py2.py3-none-any.whl (56kB)
100% |###############################| 61 KB 7,4 MB/s
Coletando urllib3<1.23,>=1.21.1 (de solicitações)
Baixando urllib3-1.22-py2.py3-none-any.whl (132kB)
100% |###############################| 133 KB 4,4 MB/s
Instalando pacotes coletados: certifi, chardet, idna, urllib3, requests
Certificado instalado com sucesso-2018.1.18 chardet-3.0.4 idna-2.6 requests-2.18.4 urllib3-1.22
```

o que não é surpreendente, já que o pip está instalado em um local diferente, portanto, não afeta mais o pip global - também significa que agora você tem um conjunto de trabalho muito interessante para python

Embora eu aprecie que o problema subjacente relatado aqui e em https://github.com/pypa/pip/issues/5221 seja o ambiente, a causa é principalmente que a importação from pip import main foi quebrada como o pacote pip.main foi movido para pip._internal.main . Seria trivial adicionar um link de pip.main para pip._internal.main para corrigir isso (enquanto consertar o ambiente é muito trabalhoso em muitos locais para muitas pessoas). Existe uma boa razão para não fazer isso?

@davidjlloyd

Este comentário fornece algumas informações sobre não fazer isso, mas não tenho certeza se isso também é importante para o próprio script pip. No entanto, resolveu o problema para mim.

@davidjlloyd Porque from pip import main nunca foi suportado, basicamente. E embora seja fácil dizer "sim, mas é uma API simples e funcionou", realmente não funcionou - tivemos vários relatórios de bugs de pessoas esperando certos comportamentos dela, que simplesmente não atendemos ( executando pip.main em vários threads, esperando que pip.main não altere a configuração do sistema de log, ...)

Em vez de continuar explicando às pessoas que elas não deveriam fazer isso e lidando continuamente com o fato de que as pessoas estão assumindo que "se eu puder encontrar uma função para chamar, ela é suportada", movemos tudo para o namespace _internal para deixe bem claro que você não deve chamá-lo.

A maior parte das reclamações veio de pessoas usando pip.main - o que é irônico, pois é tão fácil chamar pip na linha de comando suportada via subprocess . Então, de todas as possíveis quebras, esta é a mais fácil de consertar - e ainda assim as pessoas ainda não consertaram, mesmo após meses de avisos. (Embora para ser justo com as distribuições Linux, eles não suportam pessoas atualizando seus pacotes de sistema usando pip, então relatórios como # 5221 de casos em que scripts fornecidos pela distribuição quebram é fundamentalmente erro do usuário, não falha das distribuições em endereçar o pip 10 mudanças - algo que tenho certeza que eles estão lidando perfeitamente bem).

Também posso confirmar que esse problema está destruindo absolutamente meu processo anteriormente muito estável de criar uma imagem do docker, aqui estão exemplos de coisas mínimas que estou fazendo dentro do processo de criação da imagem do docker:

+ pip install -U pip setuptools
Collecting pip
  Downloading https://files.pythonhosted.org/packages/62/a1/0d452b6901b0157a0134fd27ba89bf95a857fbda64ba52e1ca2cf61d8412/pip-10.0.0-py2.py3-none-any.whl (1.3MB)
Collecting setuptools
  Downloading https://files.pythonhosted.org/packages/20/d7/04a0b689d3035143e2ff288f4b9ee4bf6ed80585cc121c90bfd85a1a8c2e/setuptools-39.0.1-py2.py3-none-any.whl (569kB)
Installing collected packages: pip, setuptools
  Found existing installation: pip 8.1.1
    Not uninstalling pip at /usr/lib/python2.7/dist-packages, outside environment /usr
Successfully installed pip-10.0.0 setuptools-39.0.1

...

+ pip install jupyter opencv-python plyfile pandas
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

A correção para nós estava fixando no pip 9.03, então:

pip install --upgrade pip==9.0.3

ao invés de

pip install -U pip

correção óbvia, mas no caso de ajudar alguém!

@peteflorence Então, presumivelmente, ao executar o docker, você está criando uma imagem base e executando pip install -U pip setuptools como root nessa imagem? Existe uma razão pela qual você precisa do pip/setuptools mais recente se tudo o que você está fazendo é instalar outros pacotes com eles? Você não poderia simplesmente atualizar para o pip/setuptools mais recente disponível como um pacote de distribuição?

Eu aprecio que isso seja um problema para você - parece ser comum que as compilações do docker sejam mais inclinadas a fazer coisas como root do que se você estivesse em um sistema operacional normal (provavelmente porque uma imagem do docker está isolada). Mas ainda não é uma boa ideia fazer isso. O problema é que o pip não gerencia /usr/bin/pip , então não temos como "consertar" isso para funcionar com o pip 10.

O que você pode fazer é mudar de /usr/bin/pip para python -m pip . Ainda não é suportado e pode atingir outros problemas (não sei quais alterações seu fornecedor de sistema operacional básico pode ter feito no pip do sistema), mas evitará o problema em /usr/bin/pip enquanto você resolve um problema mais longo. solução de prazo para o seu problema.

Fixar no pip 9 também é uma solução, mas isso levanta a questão: por que atualizar o pip do sistema operacional se o pip 9 estiver OK? Seu fornecedor não oferece uma versão empacotada do pip 9?

Em vez de continuar explicando às pessoas que elas não deveriam fazer isso e lidando continuamente com o fato de que as pessoas estão assumindo que "se eu puder encontrar uma função para chamar, ela é suportada", movemos tudo para o namespace _internal para deixar bem claro que você não deveria chamá-lo.

Não tenho certeza de que quebrar agressivamente os usos existentes de um recurso sem suporte em vez de preterir o recurso para algumas versões principais seja a melhor abordagem. Nossa reação inicial foi fixar o pip de volta ao 9.0.3, e desenvolvedores mais preguiçosos provavelmente terminariam o dia nesse ponto. Isso deixaria muitos usuários teimosamente agarrados a versões antigas, o que duvido que alguém queira. No entanto, sua motivação faz sentido, e o resultado final é o mesmo.

Para qualquer usuário que tenha esse problema, acho que a melhor solução para substituir instalações do sistema ou pyenv foi gentilmente fornecida por @standag aqui: https://github.com/pypa/pip/issues/5221#issuecomment -381568428

Esta solução deve funcionar para qualquer pessoa que esteja construindo no Docker, como @peteflorence , sem fixar em versões obsoletas ou algo horrível assim.

Pip de atualização temporária Fix usando.

curl https://bootstrap.pypa.io/get-pip.py | python3

Em vez de pip install -U pip

Para pip2 pip2 install --upgrade pip

Eu atualizei com pyenv, tanto python2 quanto python3, agora o pip2 não funciona e o pip3 funciona
Depois de comparar pip2 e pip3, a diferença é a linha de importação

pip2
from pip import main

pip3
from pip._internal import main

Depois de substituir a linha de importação pip2 pela versão pip3, funciona

To com o mesmo problema, hehe.

Mesmo problema, mas resolvido com solução: https://github.com/pypa/pip/issues/5240#issuecomment -381673100

Mesmo problema:

+ pip install --upgrade pip
Collecting pip
  Downloading https://files.pythonhosted.org/packages/62/a1/0d452b6901b0157a0134fd27ba89bf95a857fbda64ba52e1ca2cf61d8412/pip-10.0.0-py2.py3-none-any.whl
 (1.3MB)
Installing collected packages: pip
  Found existing installation: pip 8.1.1
    Not uninstalling pip at /usr/lib/python2.7/dist-packages, outside environment /usr
Successfully installed pip-10.0.0
+ pip install awscli requests simplejson
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Agora é estranho, ele instala o pip 10 em /usr/local/bin, e isso é o primeiro no PATH antes de /usr/bin, mas não o usa, não até você ir para um novo shell. Eu vi isso acontecer quando fui a esta caixa para tentar instalar um awscli mais recente manualmente ...

$ python --version
Python 2.7.12
$ pip --version
pip 10.0.0 from /usr/local/lib/python2.7/dist-packages/pip (python 2.7)
$ sudo pip install --upgrade awscli 
 <blah blah>
$ aws --version
aws-cli/1.11.13 Python/3.5.2 Linux/4.4.0-1049-aws botocore/1.4.70
$ /usr/local/bin/aws --version
aws-cli/1.15.4 Python/2.7.12 Linux/4.4.0-1049-aws botocore/1.10.4
$ which aws
/usr/local/bin/aws
$ echo $PATH
/home/ec2-user/bin:/home/ec2-user/.local/bin:/opt/bamboo-elastic-agent/bin:/opt/jdk-8/bin:/opt/maven-2.1/bin:/opt/maven-1.0.2/bin:/opt/ant-1.9/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/bin:/bin:/opt/puppetlabs/bin

@pfmoore obrigado pelos comentários. Sim, nossa imagem do docker aparentemente precisava do pip 9 e herdamos de uma imagem do docker nvidia cuda 8.0 e várias outras coisas que não devem ter. Fixar é uma boa solução para nós -- este é um sistema de pesquisa, queremos o código razoavelmente bloqueado. Mas sim, obviamente, para muitos outros, você desejará uma solução que o leve à compatibilidade com o pip 10

Agora é estranho, ele instala o pip 10 em /usr/local/bin

Eu não sou um usuário de Unix, mas lembro de ver algumas pessoas falando sobre "rehashing" no shell? Que poderia ser o problema? O bash armazena em cache as pesquisas de caminho e precisa de solicitação para refazer a pesquisa de caminho?

Sim, nossa imagem docker aparentemente precisava do pip 9 ...

Legal - certamente fixar no pip 9 é uma solução razoável no seu caso. Estou um pouco nervoso em deixar sugestões de "apenas fixar no pip 9" sem contestação, porque há um risco de que as pessoas as vejam e as copiem cegamente, apenas adiando o momento em que precisam consertar seu ambiente. Mas certamente pensar em seus requisitos e decidir que a fixação funciona para você é bom. Então, desculpe por usar seu comentário como uma caixa de sabão :-)

Fixamos no pip 9 e isso nos "consertou", mas é claro que estamos interessados ​​em poder usar o pip 10 em algum momento.

tente usar pip2 install xx @HayaoSuzuki

como voltar ao pip 9.0.0..
Ele ainda mostra o mesmo erro para mim. Por favor, escreva todos os passos

@swtt123 você pode tentar pip install pip==9.0.1

pip 10.0, eu também enfrento

AttributeError: 'module' object has no attribute 'main'

ao tentar usar pip.main(['install', '-r', 'requirements.txt'])

@p00j4 A importação de pip de dentro do seu programa não é suportada - veja os documentos

Oh! Eu entendo, no entanto, agora forçado a mudar um monte de lugares.
Obrigado @pfmoore pela cabeça.

Cuidado com o bash cacheando o local do executável:

$ which pip
/usr/bin/pip

$ pip install --user pip
Collecting pip
(...)
Successfully installed pip-10.0.0

$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

$ which pip
/usr/bin/pip

$ hash -d pip  # this clears the 'pip' entry from bash's executables locations hash table

$ which pip
/home/zwinny/.local/bin/pip

$ pip --version
pip 10.0.0 from /home/zwinny/.local/lib/python2.7/site-packages/pip (python 2.7)

Eu criei uma nova instalação do Raspbian em um Raspberry Pi 3B+. Nada de especial - configuração bonita de baunilha - e até agora, tudo correu bem.

Acabei de chegar à última etapa do meu processo de instalação:

pip install --upgrade pip

Collecting pip
  Downloading https://files.pythonhosted.org/packages/62/a1/0d452b6901b0157a0134fd27ba89bf95a857fbda64ba52e1ca2cf61d8412/pip-10.0.0-py2.py3-none-any.whl (1.3MB)
    100% |████████████████████████████████| 1.3MB 101kB/s 
Installing collected packages: pip
Successfully installed pip-10.0.0

...e agora o pip está completamente borked:

$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

De acordo com o comentário acima, confirmei que ~i/.local/bin/pip funciona bem. O erro ocorre com /usr/bin/pip. A execução de hash -d pip não atualizou o local em cache.

O downgrade forçado para 9.0.1 (via linha de opções -Iv e --force-reinstall) também não resolveu o problema. Aparentemente, a única solução, além de não atualizar o pip, é executar o pip de ~/.local/bin/pip.

python -m pip install --upgrade pip 

Trabalhou para mim. Espero que ajude alguém.

Instalei uma nova distribuição do Ubuntu hoje e tentei colocar alguns pacotes básicos do Python em funcionamento. Fui solicitado a atualizar o pip e, portanto, executei o comando que ele me disse. Este pip atualizado para a versão 10, que aparentemente está quebrado com o mesmo erro no topo deste tópico. Eu não fiz nada além do que um usuário normal faria para atualizar o pip e instalar seus pacotes favoritos. Nem mesmo usando pyenv.

Nenhuma das soluções aqui resolve meu problema. Se eu executar python -m pip install --upgrade pip recebo "Requisito já atualizado". Se eu tentar fazer o downgrade para a versão 9, recebo o mesmo erro inicial:

Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Depois de reler este tópico, a solução do @sfsdfd para usar ~/.local/bin/pip é o que finalmente funcionou:

~/.local/bin/pip install my-favourite-package

Aparentemente, isso está funcionando (com sucesso) voltando à minha versão mais antiga do pip. Adicionar isso a ~/.bashrc é uma correção melhor para mim:

export PATH=$PATH:~/.local/bin

Simplesmente reiniciar meu terminal o corrigiu para mim.

Corrigi o problema atualizando o código em /usr/bin/pip , alterando from pip import main para from pip._internal import main .

Aqui detalhes:

$ dpkg -S /usr/bin/pip
python-pip: /usr/bin/pip
$ dpkg -S /usr/bin/pip2
python-pip: /usr/bin/pip2
$ apt-file search /usr/bin/pip
colorized-logs: /usr/bin/pipetty
pipebench: /usr/bin/pipebench
pipemeter: /usr/bin/pipemeter
pipexec: /usr/bin/pipexec
python-pip: /usr/bin/pip
python-pip: /usr/bin/pip2
python3-pip: /usr/bin/pip3
rt-tests: /usr/bin/pip_stress

Depois pip install --upgrade pip :

$ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main
$ pip2
Traceback (most recent call last):
  File "/usr/bin/pip2", line 9, in <module>
    from pip import main
ImportError: cannot import name main

$ cat /usr/bin/pip
#!/usr/bin/python
# GENERATED BY DEBIAN

import sys

# Run the main entry point, similarly to how setuptools does it, but because
# we didn't install the actual entry point from setup.py, don't use the
# pkg_resources API.
from pip import main
if __name__ == '__main__':
    sys.exit(main())

Depois de atualizado o /usr/bin/pip :

$ cat /usr/bin/pip
#!/usr/bin/python
# GENERATED BY DEBIAN

import sys

# Run the main entry point, similarly to how setuptools does it, but because
# we didn't install the actual entry point from setup.py, don't use the
# pkg_resources API.
# from pip import main
from pip._internal import main
if __name__ == '__main__':
    sys.exit(main())

$ pip --version
pip 10.0.0 from /home/devops/.local/lib/python2.7/site-packages/pip (python 2.7)

$ pip2
Traceback (most recent call last):
  File "/usr/bin/pip2", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Informações do meu sistema:

$ uname -a
Linux devops-kubernetes-master 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.10
DISTRIB_CODENAME=artful
DISTRIB_DESCRIPTION="Ubuntu 17.10"
NAME="Ubuntu"
VERSION="17.10 (Artful Aardvark)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 17.10"
VERSION_ID="17.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=artful
UBUNTU_CODENAME=artful

$ python --version
Python 2.7.14

$ apt list --installed | grep python-

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libpython-all-dev/artful,now 2.7.14-2ubuntu1 amd64 [installed]
libpython-dev/artful,now 2.7.14-2ubuntu1 amd64 [installed,automatic]
libpython-stdlib/artful,now 2.7.14-2ubuntu1 amd64 [installed,automatic]
python-all/artful,now 2.7.14-2ubuntu1 amd64 [installed,automatic]
python-all-dev/artful,now 2.7.14-2ubuntu1 amd64 [installed,automatic]
python-apt-common/artful,artful,now 1.4.0~beta3build2 all [installed]
python-asn1crypto/artful,artful,now 0.22.0-1 all [installed,automatic]
python-cffi-backend/artful,now 1.9.1-2build2 amd64 [installed,automatic]
python-crypto/artful-updates,artful-security,now 2.6.1-7ubuntu0.1 amd64 [installed,automatic]
python-cryptography/artful,now 1.9-1 amd64 [installed,automatic]
python-dbus/artful,now 1.2.4-1build3 amd64 [installed,automatic]
python-dev/artful,now 2.7.14-2ubuntu1 amd64 [installed,automatic]
python-enum34/artful,artful,now 1.1.6-1 all [installed,automatic]
python-gi/artful,now 3.24.1-2build1 amd64 [installed,automatic]
python-idna/artful,artful,now 2.5-1 all [installed,automatic]
python-ipaddress/artful,artful,now 1.0.17-1 all [installed,automatic]
python-keyring/artful,artful,now 10.4.0-1 all [installed,automatic]
python-keyrings.alt/artful,artful,now 2.2-2 all [installed,automatic]
python-minimal/artful,now 2.7.14-2ubuntu1 amd64 [installed,automatic]
python-pip/artful,artful,now 9.0.1-2 all [installed]
python-pip-whl/artful,artful,now 9.0.1-2 all [installed,automatic]
python-pkg-resources/artful,artful,now 36.2.7-2 all [installed,automatic]
python-secretstorage/artful,artful,now 2.3.1-2 all [installed,automatic]
python-setuptools/artful,artful,now 36.2.7-2 all [installed,automatic]
python-setuptools-doc/artful,artful,now 36.2.7-2 all [installed]
python-six/artful,artful,now 1.10.0-4 all [installed,automatic]
python-talloc/artful,now 2.1.9-2ubuntu1 amd64 [installed]
python-wheel/artful,artful,now 0.29.0-2 all [installed,automatic]
python-xdg/artful,artful,now 0.25-4 all [installed,automatic]

Eu consertei desta forma:

$ pip --versão
Traceback (última chamada mais recente):
Arquivo "/usr/bin/pip", linha 9, em
do pip import principal
ImportError: não é possível importar o nome principal
$ sudo apt-get remove python-pip
$ sudo apt-get install python-pip
$ pip --versão
pip 10.0.0 de /home/user/.local/lib/python2.7/site-packages/pip (python 2.7)

Espero que ajude alguém.

Mesmo depois de seguir tudo, não consigo fazer o downgrade do pip. Continue recebendo erro.
Veja como consertei isso:

$ sudo apt-get remove python-pip
$ pip -v
bash: /usr/bin/pip: Nenhum arquivo ou diretório

mas quando eu tento isso$ python -m pip -Vpip 10.0.0 de /home/user/.local/lib/python2.7/site-packages/pip (python 2.7)

então eu removi a pasta completa do pip
$ sudo rm -r /home/user/.local/lib/python2.7/site-packages/pip*

então novamente eu tento isso
$ python -m pip -V
/usr/bin/pip: Nenhum módulo chamado pip

em seguida, instale o pip novamente
$ sudo apt instalar python-pip
$ python -m pip -V
pip 8.1.1 de usr/lib/python2.7/dist-packages (python 2.7)

Espero que isso resolva o problema

DEPOIS DE PERDER 3 HORAS, ISSO É O QUE RECEBI

PARA DESINSTALAR o pip 10.0.0:
sudo apt-get remove python-pip

mas então você não poderá instalar a versão correta necessária do pip pelos métodos diretos.

PARA BAIXAR PARA UMA VERSÃO DE FUNCIONAMENTO CONHECIDA APÓS A INSTALAÇÃO
quando pip10 lança o erro: ImportError: cannot import name main
você terá que executar:
python -m pip instalar pip==KNOW_WORKING_VERSION>

PARA INSTALAR QUALQUER PACOTE USANDO PIP10:
sudo python -m pip install PACKAGE_NAME
isso funcionou.

Saúde :)

Mesmo problema, corrija o problema: reinstalação completa: python-pip

apenas faça login novamente no shell como mencionado aqui
https://github.com/pypa/pip/issues/5240#issuecomment -382262586

pip3 install --upgrade pip==9.0.3
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

heh... o que eu exceto...

Acabei de desenrolar minha instalação do pip.
python -m pip install --user --upgrade pip==9.0.3

Eu queria relatar que esse problema também ocorre na compilação do Windows ao usar o AppVeyor para CI:
O resultado é o seguinte:

Running Install scripts
SET PATH=%PYTHON%;%PYTHON%\Scripts;%PATH%
pip install --disable-pip-version-check --user --upgrade pip
Collecting pip
  Downloading https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl (1.3MB)
Installing collected packages: pip
Successfully installed pip-10.0.1
pip install -U setuptools
Traceback (most recent call last):
  File "c:\python27-x64\lib\runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\python27-x64\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Python27-x64\Scripts\pip.exe\__main__.py", line 5, in <module>
ImportError: cannot import name main
Command exited with code 1

Eu tenho: pip install --disable-pip-version-check --user --upgrade pip em vários scripts appveyor.yml , com base na recomendação deste exemplo: https://github.com/ogrisel/python-appveyor-demo/blob/master/appveyor.yml #L111

Isso funcionou bem até o pip 10.x, e suspeito que se outros criaram appveyor.yml com base nisso também enfrentarão esse problema.

Mudar para easy_install -U pip funcionou, mas eu tenho vários repositórios que funcionaram antes que agora precisam ser atualizados para funcionar com pip 10.x.

Parece que a abordagem recomendada para a configuração do CI deve ser a 9.0.3 ou usar o easy_install.

Parece que a abordagem recomendada para a configuração do CI deve ser a 9.0.3 ou usar o easy_install.

A abordagem recomendada é remover a dependência de sua biblioteca/aplicativo/ferramenta dos detalhes de implementação interna do pip. easy_install não está mais sendo aprimorado ativamente pelo AFAIK e provavelmente não suporta muitas das coisas que o pip faz.

Quanto ao seu problema específico, você provavelmente pode corrigi-lo executando python -m pip install --force-reinstall pip , para corrigir o script quebrado. Caso contrário, registre um novo problema.

A abordagem recomendada é remover a dependência de sua biblioteca/aplicativo/ferramenta dos detalhes de implementação interna do pip. easy_install não está mais sendo aprimorado ativamente pelo AFAIK e provavelmente não suporta muitas das coisas que o pip faz.

Acho que você não leu o resto do post. Ele estava se referindo ao uso do easy_install para instalar o pip, não em vez do pip:

Mudar para easy_install -U pip funcionou...

Além disso, ele não está confiando nos detalhes de implementação interna do pip. Ele está usando um novo spinup do AppVeyor e atualizando o pip usando o comando que ele especificou e nada mais:

pip install --disable-pip-version-check --user --upgrade pip

Muitas outras pessoas neste tópico estão tendo o mesmo problema. Você pode reproduzir isso com uma instalação básica do pip sem fazer nada de especial ou dependente dos internos do pip. Isso foi documentado por muitas pessoas nos posts acima.

@ikreymer O problema ao qual você parece estar se referindo está no Appveyor, que executa o Windows. A questão que está sendo discutida aqui é em relação ao pyenv que é um utilitário exclusivamente Unix.

Eu não sei sobre @pradyunsg , mas estou ficando cada vez mais confuso sobre quais são os vários problemas que estão sendo discutidos. A causa raiz é fácil - pip (deliberadamente) moveu as APIs internas, e isso está causando problemas para as pessoas que confiavam nas ferramentas que as usavam, direta ou indiretamente. Mas isso não é algo que vai ser mudado. Portanto, se quisermos ajudar os usuários a encontrar uma solução para seus problemas específicos, precisamos manter a discussão focada em um problema de cada vez.

Então, posso perguntar - se você precisar de ajuda com um problema no Appveyor, por favor, abra um novo problema que descreva o problema, e vamos realocar a discussão para lá. (A maioria dos detalhes provavelmente está em seu comentário, então isso servirá como ponto de partida para o problema, mas uma descrição completa de como reproduzir o problema em um novo projeto Appveyor seria imensamente útil para nos ajudar a diagnosticar o problema .

@arvoelke :

Ele estava se referindo ao uso do easy_install para instalar o pip, não em vez do pip

Instalar o pip usando easy_install pode ter problemas e, se isso acontecer, não poderemos apoiá-lo, porque (como disse @pradyunsg ) easy_install é antigo, não é mantido ativamente e faltando recursos recentes. Mas se funciona para você, e você não precisa de nossa ajuda, então tudo bem - ninguém está parando você.

Muitas outras pessoas neste tópico estão tendo o mesmo problema

Defina "o mesmo". Se você quer dizer "ver erros do código que importa pip.main , então sim, mas isso não é um problema com o pip, é uma mudança deliberada, incompatível com versões anteriores, para a implementação interna do pip. Se você quiser que digamos apenas " difícil, você não deveria estar usando as APIs internas do pip", então tudo bem - um único problema é suficiente, e vamos fechá-lo como "não é um bug". Mas se você quiser que nós o ajudemos a descobrir o que parte do seu ambiente falhou em seguir o conselho publicado há 6 meses e encontrar uma solução alternativa para você que permite continuar usando o pip enquanto seu ambiente é corrigido pelo fornecedor, então você terá que nos ajudar a ajudá-lo. dizer "Eu tenho o mesmo problema" em um relatório sobre um utilitário puramente Unix, quando você está executando no Windows, definitivamente não está nos ajudando a ajudá-lo ...

A questão que está sendo discutida aqui é em relação ao pyenv que é um utilitário exclusivamente Unix.

Uma das primeiras respostas a este tópico foi:

O mesmo aqui .. Exatamente a mesma saída que @HayaoSuzuki e não usamos pyenv

O aspecto pyenv parece mais ou menos secundário com base nos comentários acima e problemas e commits vinculados, incluindo aqueles que ocorrem em novas instalações do Ubuntu e RaspberryPi. Novamente, tudo isso já faz parte desta questão. A causa raiz é "a mesma" (ou seja, atualizar o pip e tentar iniciá-lo) para todos, incluindo o OP, e assim podemos criar mais problemas, mas não há realmente nada diferente acontecendo entre eles - apenas em como o problema se manifesta.

E dizer "eu tenho o mesmo problema" em um relatório sobre um utilitário puramente Unix, quando você está executando no Windows, definitivamente não está nos ajudando a ajudá-lo ...

Não estou executando no Windows. Estou rodando no Ubuntu como eu disse antes. O outro pôster está usando o Windows, mas eles estão simplesmente atualizando o pip e executando o pip, assim como o resto de nós nesta edição. Existe um consenso bastante comum de que o uso de pyenv não é fundamental para o problema.

Todos esses problemas parecem resultar do mesmo problema: atualizar o pip, mas continuar usando um lançador antigo que ainda usa o antigo ponto de entrada. Uma boa maneira de evitar esse tipo de problema é usar python -m pip .

Todos esses problemas parecem resultar do mesmo problema: atualizar o pip, mas continuar usando um lançador antigo que ainda usa o antigo ponto de entrada. Uma boa maneira de evitar esse tipo de problema é usar python -m pip.

Sim, acho que essa parece ser a raiz do problema e acontece em todas as diferentes plataformas mencionadas neste tópico, incluindo o Windows.

Caso isso ajude mais alguém, posso confirmar que mudar a atualização do pip appveyor.yml de:

pip install --disable-pip-version-check --user --upgrade pip

para:

python -m pip install --upgrade pip

corrige o problema. Agora para atualizar vários outros repositórios!

Eu encontrei o mesmo sintoma discutido aqui em uma situação diferente.

Eu estava tentando usar um pip instalado localmente, em um sistema Ubuntu 16.0.4:

curl -O https://bootstrap.pypa.io/get-pip.py
export PYTHONUSERBASE=$(pwd)
python ./get-pip.py --user
export PYTHONPATH=$(pwd)/lib/python2.7/site-packages

python ./bin/pip --version

Traceback (most recent call last):
  File "/path/to/bin/pip", line 7, in <module>
    from pip._internal import main
ImportError: No module named _internal

Descobriu-se que o Ubuntu precede um caminho específico do pip para sys.path via site.py , que estava substituindo meu PYTHONPATH , mostrado abaixo:

import sys
print(sys.path)
['', '/usr/local/lib/python2.7/dist-packages/pip-9.0.1-py2.7.egg', '/path/to/lib/python2.7/site-packages`, ...]

Eu tentei evitar o prefixo com -S flag para python, documentado na página man como:

-S Desabilite a importação do site do módulo e as manipulações dependentes do site de sys.path que isso implica.

e funcionou:

python -S ./bin/pip --version

pip 10.0.1 from path/to/bin/pip (python 2.7)

Compartilhando caso isso possa ajudar outras pessoas - Na minha imagem do docker (a base é ubuntu:xenial ), recebi o seguinte erro:

Step 8/12 : RUN pip install -U pip  && pip install -r /tmp/requirements.txt
 ---> Running in e4ff51b013f0
Collecting pip
  Downloading https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl (1.3MB)
Installing collected packages: pip
  Found existing installation: pip 8.1.1
    Not uninstalling pip at /usr/lib/python2.7/dist-packages, outside environment /usr
Successfully installed pip-10.0.1
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Mudei pip install -U pip && pip install -r /tmp/requirements.txt para pip2 install -U pip && pip2 install -r /tmp/requirements.txt . Isso resolveu o problema.

Não tenho certeza se vi uma resposta/resposta ao comentário de @davidjlloyd :

Não tenho certeza de que quebrar agressivamente os usos existentes de um recurso sem suporte em vez de preterir o recurso para algumas versões principais seja a melhor abordagem.

Posso perguntar por que não houve um processo de descontinuação para isso?
Parece que teria sido bem fácil, no import de pip , verifique sys.argv[0] ; se não for pip ou pipX[.Y] , lance alguns DeprecationWarning s que isso falhará na versão X+, com um link para o que você mencionou: https://pip.pypa. io/en/latest/user_guide/#using -pip-from-your-program

Existe um processo em vigor para tentar garantir que esse tipo de coisa seja evitado no futuro?

Não tenho certeza se vi uma resposta/resposta ao comentário de @davidjlloyd :

Foi respondido repetidamente, talvez não sobre esse problema específico, mas uma pesquisa no rastreador de problemas deve encontrar muita discussão sobre o assunto.

Posso perguntar por que não houve um processo de descontinuação para isso?

Porque nunca foi apoiado. Por que alertaríamos que estamos desmantelando algo que nunca apoiamos? As pessoas presumiam que não havia problema em ler o código-fonte do pip e usar as funções que encontraram lá em seu próprio código. Nunca foi. Dissemos que poderia quebrar, e no pip 10 quebrou.

Parece que teria sido bem fácil, na importação do pip, verifique sys.argv[0]; se não for pip ou pipX[.Y], lance alguns DeprecationWarnings

Não tenho certeza se é tão fácil quanto você pensa. E digo isso da perspectiva de alguém que teve que lidar com problemas em que os avisos adicionados no pip 10 estavam sendo acionados quando não esperávamos que fossem ...

E, novamente, não há necessidade de descontinuar algo que não é suportado em primeiro lugar.

Existe um processo em vigor para tentar garantir que esse tipo de coisa seja evitado no futuro?

Que tipo de coisa? Quebra causada por nós mudando coisas para as quais não garantimos compatibilidade com versões anteriores? Não. Não há necessidade de evitarmos isso. Embora, na verdade, tentemos gerenciar o processo, como uma cortesia para nossos usuários ( não uma obrigação!). Nesse caso, divulgamos a mudança com 6 meses de antecedência, oferecemos sugestões para as pessoas que precisavam alterar seu código e passamos muito tempo desde o lançamento ajudando usuários que tiveram problemas porque o software em que confiam não atendeu esses avisos. É muito trabalho que um grupo de voluntários muito pequeno colocou para tentar mitigar uma situação causada por pessoas esperando apoio que nunca foi oferecido ou prometido. De nada.

Temos processos (avisos de descontinuação, etc.) para alterar coisas para as quais garantimos compatibilidade - mas importar pip para seu próprio programa não é um deles.

Eu tinha um script bash que instalou o frasco e solicita a atualização quebrou meu script, mas eu entendo os motivos mencionados acima. Meu trabalho para manter meu script funcionando foi simplesmente lançar um novo processo bash, talvez isso esteja errado, mas funcionou para mim. Espero que possa ajudar outras pessoas com scripts semelhantes.

pip install --upgrade pip
echo "pip install Flask" | bash
echo "pip install requests" | bash

@OneLogicalMyth o que você está procurando pode ser hash -d pip , consulte https://github.com/pypa/pip/issues/5221#issuecomment -381568428.

perdi completamente que, mesmo depois de ler com atenção, obrigado @austinbutler , isso resolveu meu problema.

A única razão pela qual esse problema foi mantido aberto e não fechado como uma duplicata imediatamente foi porque eu estava preocupado se o pyenv faz algo com calços e se o pip precisaria ajudar de alguma forma. Não foi esse o caso, então esta questão está encerrada agora.

Eu listei as soluções alternativas antes (todas elas triviais) para quase todos esses problemas mencionados aqui - dê uma olhada em https://github.com/pypa/pip/issues/5221#issuecomment -382069604. Espero que isso resolva todas as preocupações levantadas nesta edição. Se isso não acontecer, por favor abra um novo problema.

@benoit-pierre Eu adicionei sua sugestão de usar python -m pip ao comentário vinculado. Obrigado por isso. :)

Instalar o pip usando o easy_install pode ter problemas e, se isso acontecer, não poderemos apoiá-lo, porque (como disse @pradyunsg ) o easy_install é antigo, não é mantido ativamente e está faltando recursos recentes.

Obrigado por esclarecer minha posição @pfmoore. É disso que eu estava falando.

Estou ficando cada vez mais confuso sobre quais são os vários problemas que estão sendo discutidos.

Eu também.

Apenas algumas dicas gerais (pegar ou largar), sobre coisas que vi nesta edição:

• Se o comando pip não funcionar por algum motivo, tente executar python -m pip . As chances são de que python -m pip funcionará para você mesmo se seus scripts de wrapper quebrarem. Se não funcionar, abra um novo problema.
• Não execute pip como root ou faça sudo pip . Você provavelmente quebrará seu sistema e, se isso não for ruim o suficiente, você estará executando a execução remota de código como root.
• Não use easy_install pelos motivos citados no início deste comentário. Aqui está mais contexto (que está um pouco desatualizado).
• Por favor, não fixe no pip 9. Eu acredito fortemente que fazer isso é agir ativamente para retardar o progresso do Python Packaging em geral.
  
  
  
  • O pip 9 nunca suportará o PEP 517/518 e permanecer no pip 9 significa que você terá que se esforçar para mudar mais tarde, quando um pacote quebrar no último minuto porque eles mudam para os padrões de embalagem mais recentes.
  
  

Para resumir, isso provavelmente não é culpa de um único projeto/pessoa e todos estão bem fundamentados para tomar suas ações. Sim, seu ambiente quebrou. Nós entendemos. Não jogue a culpa em pessoas que estão oferecendo seu tempo livre, para ajudá-lo agora e desenvolver pip.

Quer nos ajudar? https://donate.pypi.org é uma coisa e, se não , esse não é o seu tipo de coisa , há muitos problemas em aberto neste rastreador de problemas com os quais você pode nos ajudar.

Vou me afastar desse assunto agora.

Ok, uma última coisa, se alguém ainda quiser discutir sobre nossa decisão de mover toda a nossa base de código para pip._internal , abra um novo problema e me dê uma menção. Vou gastar algum tempo para escrever algo com links e tudo, sobre por que pip fez isso. Dessa forma, @pypa/pip-committers teria um único lugar para as pessoas linkarem neste tópico.

Por enquanto, isso funcionou em python3 / pip3 , para reverter

python3 -m pip install --user --upgrade pip==9.0.3

@freckletonj Por favor, não diga às pessoas para reverter para o pip 9. Não é assim que você deve resolver esse problema. Existem maneiras muito melhores.

Eu vinculei a um comentário logo acima do seu, listando maneiras de resolver esse problema.

desculpe @pradyunsg , mas isso ainda não funciona:

$ pip3 install --upgrade --user pip
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 9.0.3
    Uninstalling pip-9.0.3:
      Successfully uninstalled pip-9.0.3
Successfully installed pip-10.0.1
$ pip3
Traceback (most recent call last):
  File "/usr/local/bin/pip3", line 7, in <module>
    from pip import main
ImportError: cannot import name 'main'

De https://github.com/pypa/pip/issues/5221#issuecomment -382069604, ao qual vinculei acima:

hash -r pip # or hash -d pip

Se alguém tiver alguma outra dúvida, por favor, abra um novo tópico.

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 dessa edição está aberta para que os usuários discutam problemas e soluções específicas. :)