Salut @KleinerNull !

Je n'ai aucune idée si cela a quelque chose à voir avec la mise à niveau elle-même ou avec pyenv comme environnement.

Je pense que c'est une question d'environnement. Je vous suggère d'ouvrir un problème sur pyenv car je pense que les gens là-bas seraient mieux placés pour commenter / résoudre ce problème.

@pradyunsg

J'ai ouvert un sujet sur le repo pyenv.

Nous souffrons également de celui-ci, il a cassé notre pipeline. Opération en cours :

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

Ubuntu 16.04
Python3.6

Nous rencontrons le même souci.

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

Idem ici .. Exactement la même sortie que @HayaoSuzuki et nous n'utilisons pas pyenv

Si vous obtenez cela en dehors de pyenv, je soupçonne qu'il est plus susceptible d'être lié à # 5221

Juste pour mentionner que pip install --user --upgrade pip sur Ubuntu 16.04 se casse également.

Une installation intéressante et facile pip installe 10.0.0 mais ne présente pas le problème
```
// dans l'hôte
$ docker pull ubuntu:xenial
$ docker run --name pip-test --rm -it ubuntu:xenial bash

// dans le conteneur

mise à jour appropriée

apt install -y python-setuptools

pip easy_install

Installé /usr/local/lib/python2.7/dist-packages/pip-10.0.0-py2.7.egg
Traitement des dépendances pour pip
Fini le traitement des dépendances pour pip

demandes d'installation pip

Collecte des demandes
Téléchargement de demandes-2.18.4-py2.py3-none-any.whl (88kB)
100% |################################| 92 Ko 2,9 Mo/s
Collecte des certifi>=2017.4.17 (à partir des demandes)
Téléchargement de certifi-2018.1.18-py2.py3-none-any.whl (151kB)
100% |################################| 153 Ko 4,4 Mo/s
Collecte chardet<3.1.0,>=3.0.2 (à partir des requêtes)
Téléchargement de chardet-3.0.4-py2.py3-none-any.whl (133kB)
100% |################################| 143 Ko 4,5 Mo/s
Collecte idna<2.7,>=2.5 (à partir des requêtes)
Téléchargement de idna-2.6-py2.py3-none-any.whl (56kB)
100% |################################| 61 Ko 7,4 Mo/s
Collecte urllib3<1.23,>=1.21.1 (à partir des requêtes)
Téléchargement de urllib3-1.22-py2.py3-none-any.whl (132kB)
100% |################################| 133 Ko 4,4 Mo/s
Installation des packages collectés : certifi, chardet, idna, urllib3, requests
Installé avec succès certifi-2018.1.18 chardet-3.0.4 idna-2.6 requests-2.18.4 urllib3-1.22
```

ce qui n'est pas surprenant, puisque ce pip est installé dans un œuf à un endroit différent, n'affectant donc plus le pip global - cela signifie également que vous avez maintenant un ensemble de travail très intéressant pour python

Bien que je comprenne que le problème sous-jacent signalé ici et dans https://github.com/pypa/pip/issues/5221 est l'environnement, la cause est principalement que l'importation from pip import main a été cassée en tant que package pip.main a été déplacé vers pip._internal.main . Il serait trivial d'ajouter un lien de pip.main à pip._internal.main pour résoudre ce problème (alors que la réparation de l'environnement représente beaucoup de travail dans de nombreux endroits pour de nombreuses personnes). Y a-t-il une bonne raison de ne pas le faire ?

@davidjlloyd

Ce commentaire donne quelques informations sur le fait de ne pas le faire, mais je ne suis pas tout à fait sûr que cela soit également important pour le script pip lui-même. Cependant, cela a résolu le problème pour moi.

@davidjlloyd Parce que from pip import main n'a jamais été pris en charge, en gros. Et même s'il est facile de dire "oui, mais c'est une API simple et ça a juste fonctionné", ce n'est vraiment pas le cas - nous avons eu plusieurs rapports de bogues de la part de personnes qui s'attendent à certains comportements de sa part, que nous ne prenons tout simplement pas en compte ( exécutant pip.main dans plusieurs threads, s'attendant à ce que pip.main ne modifie pas la configuration du système de journalisation, ...)

Plutôt que de continuer à expliquer aux gens qu'ils ne devraient pas le faire, et de gérer continuellement le fait que les gens supposent que "si je peux trouver une fonction à appeler, elle est prise en charge", nous avons tout déplacé vers l'espace de noms _internal pour faites bien comprendre que vous n'êtes pas censé l'appeler.

La plupart des plaintes proviennent de personnes utilisant pip.main - ce qui est ironique, car il est si facile d'appeler pip dans la ligne de commande prise en charge via subprocess . Donc, de toutes les pannes possibles, c'est la plus facile à réparer - et pourtant les gens ne l'ont toujours pas réparé, même après des mois d'avertissements. (Bien que pour être juste envers les distributions Linux, ils ne prennent pas en charge les personnes mettant à niveau leurs packages système à l'aide de pip, donc des rapports comme # 5221 de cas où la rupture des scripts fournis par la distribution est fondamentalement une erreur de l'utilisateur, pas un échec des distributions pour résoudre le pip 10 changements - quelque chose dont je suis sûr qu'ils gèrent parfaitement bien).

Je peux également confirmer que ce problème détruit absolument mon processus auparavant très stable de création d'une image docker, voici des exemples de choses minimales que je fais dans mon processus de construction d'image 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

Le correctif pour nous était d'épingler le pip 9.03, donc :

pip install --upgrade pip==9.0.3

au lieu de

pip install -U pip

solution évidente mais au cas où cela aiderait quelqu'un d'autre!

@peteflorence Donc, vraisemblablement, lors de l'exécution de docker, vous créez une image de base, puis exécutez pip install -U pip setuptools en tant que root dans cette image? Y a-t-il une raison pour laquelle vous avez besoin des derniers pip/setuptools si tout ce que vous faites est d'installer d'autres packages avec eux ? Ne pourriez-vous pas simplement mettre à niveau vers les derniers pip/setuptools disponibles en tant que package de distribution ?

Je comprends que c'est un problème pour vous - il semble être courant que les versions de docker soient plus enclines à faire des choses en tant que root que si vous étiez dans un système d'exploitation normal (probablement parce qu'une image de docker est isolée). Mais ce n'est toujours pas une bonne idée de le faire. Le problème est que pip ne gère pas /usr/bin/pip , nous n'avons donc aucun moyen de "réparer" cela pour fonctionner avec pip 10.

Ce que vous pourriez faire est de passer de l'utilisation de /usr/bin/pip à l'utilisation python -m pip . Il n'est toujours pas pris en charge et peut rencontrer d'autres problèmes (je ne sais pas quels changements votre fournisseur de système d'exploitation de base a pu apporter au système pip), mais cela évitera le problème dans /usr/bin/pip pendant que vous triez un plus long- solution à long terme à votre problème.

Épingler sur pip 9 est également une solution, mais cela soulève la question suivante : pourquoi mettre à jour votre système d'exploitation pip si pip 9 est OK ? Votre fournisseur ne propose-t-il pas une version packagée de pip 9 ?

Plutôt que de continuer à expliquer aux gens qu'ils ne devraient pas le faire, et de gérer continuellement le fait que les gens supposent "si je peux trouver une fonction à appeler, elle est prise en charge", nous avons tout déplacé vers l'espace de noms _internal pour qu'il soit très clair que vous n'êtes pas censé l'appeler.

Je ne suis pas sûr que briser de manière agressive les utilisations existantes d'une fonctionnalité non prise en charge au lieu de déprécier la fonctionnalité pour quelques versions majeures soit la meilleure approche. Notre réaction initiale a été de ramener pip à la version 9.0.3, et les développeurs plus paresseux l'appelleraient probablement un jour à ce moment-là. Cela laisserait beaucoup d'utilisateurs s'accrocher obstinément aux anciennes versions, ce que je doute que quiconque veuille. Cependant, votre motivation a du sens et le résultat final est le même.

Pour tous les utilisateurs rencontrant ce problème, je pense que la meilleure solution pour remplacer les installations système ou pyenv a été aimablement fournie par @standag ici : https://github.com/pypa/pip/issues/5221#issuecomment -381568428

Cette solution devrait fonctionner pour tous ceux qui construisent dans Docker, tels que @peteflorence , sans épingler des versions obsolètes ou quoi que ce soit d'horrible comme ça.

Correction temporaire de l'utilisation du pip de mise à niveau.

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

Au lieu de pip install -U pip

Pour pip2 pip2 install --upgrade pip

J'ai mis à jour avec pyenv, à la fois python2 et python3, maintenant pip2 ne fonctionne pas et pip3 fonctionne
Après avoir comparé pip2 et pip3, la différence est la ligne d'importation

pip2
from pip import main

pip3
from pip._internal import main

Après avoir remplacé la ligne d'importation pip2 par la version pip3, cela fonctionne

Ayant le même problème, hein.

Même problème, mais résolu avec une solution : https://github.com/pypa/pip/issues/5240#issuecomment -381673100

Même problème:

+ 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

Maintenant, c'est bizarre, il installe pip 10 sur /usr/local/bin, et c'est d'abord dans le PATH avant /usr/bin, mais il ne l'utilise pas, pas avant d'aller dans un nouveau shell. J'ai vu cela se produire lorsque je suis allé dans cette boîte pour essayer d'installer un awscli plus récent à la main...

$ 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 merci pour les commentaires. Oui, notre image docker avait apparemment besoin de pip 9 et nous héritons d'une image docker nvidia cuda 8.0 et d'un tas d'autres choses qui ne devaient pas l'avoir. L'épinglage est une bonne solution pour nous -- c'est un système de recherche, nous voulons que le code soit raisonnablement verrouillé. Mais oui, évidemment pour beaucoup d'autres, vous voudrez une solution qui vous amène à la compatibilité avec pip 10

Maintenant c'est bizarre, il installe pip 10 sur /usr/local/bin

Je ne suis pas un utilisateur d'Unix, mais je me souviens avoir vu certaines personnes parler de "rehashing" dans le shell ? Cela pourrait-il être le problème? Bash cache les recherches de chemin et a-t-il besoin d'être invité à refaire la recherche de chemin ?

Oui notre image docker avait apparemment besoin de pip 9...

Cool - certainement épingler au pip 9 est une solution raisonnable dans votre cas. Je suis un peu nerveux à l'idée de laisser les suggestions "juste épingler au pip 9" sans contestation, car il y a un risque que les gens les voient et les copient aveuglément, reportant simplement le moment où ils doivent réparer leur environnement. Mais il est certain que penser à vos besoins et décider que l'épinglage fonctionne pour vous est très bien. Alors excusez-moi d'avoir utilisé votre commentaire comme une tribune :-)

Nous avons épinglé le pip 9 et cela nous a "fixés", mais bien sûr, nous souhaitons pouvoir utiliser le pip 10 à un moment donné.

essayez d'utiliser pip2 install xx @HayaoSuzuki

comment revenir au pip 9.0.0..
Il me montre toujours la même erreur. Veuillez écrire toutes les étapes

@ swtt123 vous pouvez essayer pip install pip==9.0.1

pip 10.0, je suis aussi confronté

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

en essayant d'utiliser pip.main(['install', '-r', 'requirements.txt'])

@ p00j4 L'importation de pip depuis votre programme n'est pas prise en charge - voir la documentation

Oh! Je comprends cependant, maintenant obligé de changer beaucoup d'endroits.
Merci @pfmoore pour la tête.

Faites attention à la mise en cache bash de l'emplacement de l'exécutable :

$ 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)

J'ai créé une nouvelle installation Raspbian sur un Raspberry Pi 3B+. Rien de spécial - jolie configuration vanille - et jusqu'à présent, tout s'est bien passé.

Je viens d'atteindre la toute dernière étape de mon processus d'installation :

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

...et maintenant pip est complètement bourré :

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

Selon le commentaire ci-dessus, j'ai confirmé que ~i/.local/bin/pip fonctionne bien. L'erreur se produit avec /usr/bin/pip. L'exécution de hash -d pip n'a cependant pas mis à jour l'emplacement du cache.

La rétrogradation forcée vers la version 9.0.1 (via la ligne d'options -Iv et --force-reinstall) n'a pas non plus résolu le problème. Apparemment, la seule solution, en plus de ne pas mettre à jour pip, consiste à exécuter pip à partir de ~/.local/bin/pip.

python -m pip install --upgrade pip 

A travaillé pour moi. J'espère que cela aide quelqu'un.

J'ai installé une nouvelle distribution Ubuntu aujourd'hui et j'ai essayé de faire fonctionner des packages Python de base. J'ai été invité à mettre à jour pip, et j'ai donc exécuté la commande qu'il m'a dit. Ce pip mis à niveau vers la version 10, qui est apparemment cassé avec la même erreur en haut de ce fil. Je n'ai rien fait d'autre que ce qu'un utilisateur normal ferait pour mettre à jour pip et installer ses packages préférés. Même pas en utilisant pyenv.

Aucune des solutions ici ne résout mon problème. Si j'exécute python -m pip install --upgrade pip , j'obtiens "Exigence déjà à jour". Si j'essaie de rétrograder vers la version 9, j'obtiens la même erreur initiale :

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

Après avoir relu ce fil, la solution de @sfsdfd pour utiliser ~/.local/bin/pip est ce qui a finalement fonctionné :

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

Apparemment, cela fonctionne en revenant (avec succès) à mon ancienne version de pip. Ajouter ceci à ~/.bashrc est une meilleure solution pour moi :

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

Redémarrer simplement mon terminal l'a corrigé pour moi.

J'ai résolu le problème en mettant à jour le code dans /usr/bin/pip , en remplaçant from pip import main par from pip._internal import main .

Voici les détails :

$ 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

Après 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())

Après avoir mis à jour le /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

Mes informations système :

$ 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]

J'ai corrigé de cette façon:

$ pip --version
Traceback (dernier appel le plus récent) :
Fichier "/usr/bin/pip", ligne 9, dans
de pip import principal
ImportError : impossible d'importer le nom principal
$ sudo apt-get supprimer python-pip
$ sudo apt-get install python-pip
$ pip --version
pip 10.0.0 depuis /home/user/.local/lib/python2.7/site-packages/pip (python 2.7)

J'espère que cela aide quelqu'un.

Même après avoir tout suivi, je ne suis pas en mesure de rétrograder pip. Continuez à recevoir une erreur.
Voici comment j'ai corrigé cela :

$ sudo apt-get supprimer python-pip
$ pip -v
bash : /usr/bin/pip : aucun fichier ou répertoire de ce type

mais quand j'essaye ça$ python -m pip -Vpip 10.0.0 depuis /home/user/.local/lib/python2.7/site-packages/pip (python 2.7)

donc j'ai supprimé le dossier complet de pip
$ sudo rm -r /home/user/.local/lib/python2.7/site-packages/pip*

encore une fois j'essaie ça
$ python -m pip -V
/usr/bin/pip : aucun module nommé pip

puis réinstallez pip
$ sudo apt install python-pip
$ python -m pip -V
pip 8.1.1 de usr/lib/python2.7/dist-packages (python 2.7)

J'espère que cette solution est le problème

APRÈS AVOIR PERDU 3 HEURES, VOICI CE QUE J'AI OBTENU

POUR DÉSINSTALLER pip 10.0.0 :
sudo apt-get supprimer python-pip

mais alors vous ne pourrez pas installer la bonne version requise de pip par les méthodes directes.

POUR PASSER À UNE VERSION DE TRAVAIL CONNUE APRÈS L'INSTALLATION
lorsque pip10 génère l'erreur : ImportError : impossible d'importer le nom principal
vous devrez exécuter:
python -m pip installer pip==KNOW_WORKING_VERSION>

POUR INSTALLER N'IMPORTE QUEL FORFAIT UTILISANT PIP10 :
sudo python -m pip installer PACKAGE_NAME
cela a fonctionné.

Acclamations :)

Même problème, problème résolu : réinstallation complète : python-pip

reconnectez-vous simplement au shell comme mentionné ici
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'

hé... qu'est-ce que j'ai mis à part...

Je viens de dérouler mon installation pip.
python -m pip install --user --upgrade pip==9.0.3

Je voulais signaler que ce problème se produit également sur la version Windows lors de l'utilisation d'AppVeyor pour CI :
Le résultat est le suivant :

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

J'ai : pip install --disable-pip-version-check --user --upgrade pip dans plusieurs scripts appveyor.yml , sur la base de la recommandation de cet exemple : https://github.com/ogrisel/python-appveyor-demo/blob/master/appveyor.yml #L111

Cela a bien fonctionné jusqu'à pip 10.x, et je soupçonne que si d'autres ont créé appveyor.yml sur cette base, ils rencontreront également ce problème.

Le passage à easy_install -U pip a fonctionné, mais j'ai plusieurs dépôts qui fonctionnaient auparavant et qui doivent maintenant être mis à jour pour fonctionner avec pip 10.x.

Il semble que l'approche recommandée pour la configuration CI devrait s'en tenir à 9.0.3 ou utiliser easy_install.

Il semble que l'approche recommandée pour la configuration CI devrait s'en tenir à 9.0.3 ou utiliser easy_install.

L'approche recommandée consiste à supprimer la dépendance de votre bibliothèque/application/outil des détails d'implémentation interne de pip. AFAIK, easy_install n'est plus activement amélioré et ne prend probablement pas en charge beaucoup de choses que pip fait.

En ce qui concerne votre problème spécifique, vous pouvez probablement le résoudre en exécutant python -m pip install --force-reinstall pip , pour réparer le script défectueux. Si ce n'est pas le cas, veuillez déposer un nouveau problème.

L'approche recommandée consiste à supprimer la dépendance de votre bibliothèque/application/outil des détails d'implémentation interne de pip. AFAIK, easy_install n'est plus activement amélioré et ne prend probablement pas en charge beaucoup de choses que pip fait.

Je suppose que tu n'as pas lu le reste de son message. Il faisait référence à l'utilisation d'easy_install pour installer pip, pas à la place de pip :

Le passage à easy_install -U pip a fonctionné...

De plus, il ne s'appuie pas sur les détails d'implémentation interne de pip. Il utilise une nouvelle version d'AppVeyor et met à jour pip à l'aide de la commande qu'il a spécifiée, et rien de plus :

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

Beaucoup d'autres personnes dans ce fil ont le même problème. Vous pouvez reproduire cela avec une installation de base de pip sans rien faire de spécial ou dépendre des composants internes de pip. Cela a été documenté par de nombreuses personnes dans les messages ci-dessus.

@ikreymer Le problème auquel vous semblez faire référence concerne Appveyor, qui exécute Windows. Le problème discuté ici concerne pyenv qui est un utilitaire exclusivement Unix.

Je ne sais pas pour @pradyunsg , mais je suis de plus en plus confus quant aux différents problèmes discutés. La cause première est simple - pip a (délibérément) déplacé les API internes, ce qui cause des problèmes aux personnes qui s'appuyaient sur des outils qui les utilisaient, directement ou indirectement. Mais ce n'est pas quelque chose qui va changer. Donc, si nous voulons aider les utilisateurs à trouver une solution à leurs problèmes spécifiques, nous devons garder la discussion centrée sur un problème à la fois.

Alors puis-je demander - si vous avez besoin d'aide pour un problème sur Appveyor, pourriez-vous ouvrir un nouveau problème qui décrit le problème, et nous déplacerons la discussion là-bas. (La plupart des détails sont probablement dans votre commentaire, donc cela servira de point de départ pour le problème, mais une description complète de la façon de reproduire le problème dans un tout nouveau projet Appveyor serait extrêmement utile pour nous aider à diagnostiquer le problème .

@arvoelke :

Il faisait référence à l'utilisation d'easy_install pour installer pip, pas à la place de pip

L'installation de pip en utilisant easy_install pourrait bien avoir des problèmes, et si c'est le cas, nous ne pourrons pas vous aider, car (comme @pradyunsg l' a dit) easy_install est vieux, pas activement maintenu, et fonctionnalités récentes manquantes. Mais si cela fonctionne pour vous et que vous n'avez pas besoin de notre aide, alors très bien - personne ne vous en empêche.

Beaucoup d'autres personnes dans ce fil ont le même problème

Définissez "le même". Si vous voulez dire "voir des erreurs du code qui importe pip.main alors oui, mais ce n'est pas un problème avec pip, c'est un changement délibéré, rétrocompatible, de l'implémentation interne de pip. dur, vous ne devriez pas utiliser les API internes de pip", alors très bien - un seul problème suffit, et nous le fermerons simplement comme "pas un bogue". Mais si vous voulez que nous vous aidions à déterminer ce une partie de votre environnement n'a pas suivi les conseils publiés il y a 6 mois, et trouver une solution de contournement pour vous qui vous permette de continuer à utiliser pip pendant que votre environnement est réparé par le fournisseur, alors vous devrez nous aider à vous aider. dire "j'ai le même problème" sur un rapport concernant un utilitaire purement Unix, lorsque vous tournez sous Windows, ne nous aide certainement pas à vous aider...

La question discutée ici est en relation avec pyenv qui est un utilitaire exclusivement Unix.

L'une des premières réponses à ce fil était:

Idem ici .. Exactement la même sortie que @HayaoSuzuki et nous n'utilisons pas pyenv

L'aspect pyenv semble plus ou moins secondaire sur la base des commentaires ci-dessus et des problèmes et commits liés, y compris ceux qui se produisent sur de nouvelles installations d'Ubuntu et de RaspberryPi. Encore une fois, tout cela fait déjà partie de ce problème. La cause première est "la même" (c'est-à-dire mettre à niveau pip puis essayer de le lancer) pour tout le monde, y compris l'OP, et nous pouvons donc créer plus de problèmes, mais il n'y a vraiment rien de différent entre eux - seulement dans comment le problème se manifeste.

Et dire "j'ai le même problème" sur un rapport concernant un utilitaire purement Unix, lorsque vous tournez sous Windows, ne nous aide certainement pas à vous aider...

Je ne tourne pas sous Windows. Je cours sur Ubuntu comme je l'ai dit auparavant. L'autre affiche utilise Windows, mais ils mettent simplement à jour pip et exécutent pip, tout comme le reste d'entre nous dans ce numéro. Il existe un consensus assez commun sur le fait que l'utilisation de pyenv n'est pas fondamentale pour le problème.

Tous ces problèmes semblent provenir du même problème : mettre à niveau pip, mais continuer à utiliser un ancien lanceur qui utilise toujours l'ancien point d'entrée. Un bon moyen d'éviter ce genre de problème est d'utiliser python -m pip .

Tous ces problèmes semblent provenir du même problème : mettre à niveau pip, mais continuer à utiliser un ancien lanceur qui utilise toujours l'ancien point d'entrée. Un bon moyen d'éviter ce genre de problème est d'utiliser python -m pip.

Oui, je pense que cela semble être la racine du problème et se produit sur toutes les différentes plates-formes mentionnées dans ce fil, y compris Windows.

Au cas où cela aiderait quelqu'un d'autre, je peux confirmer que la mise à niveau de pip appveyor.yml à partir de :

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

pour:

python -m pip install --upgrade pip

résout le problème. Maintenant, pour mettre à jour plusieurs autres dépôts !

J'ai rencontré le même symptôme discuté ici dans une situation différente.

J'essayais d'utiliser un pip installé localement, sur un système 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

Il s'est avéré qu'Ubuntu ajoute un chemin spécifique au pip à sys.path via site.py , qui écrasait mon PYTHONPATH , illustré ci-dessous :

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`, ...]

J'ai essayé d'éviter le préfixe avec l'indicateur -S pour python, documenté dans la page de manuel comme suit :

-S Désactiver l'import du site du module et les manipulations dépendant du site de sys.path qu'il implique.

et ça a marché :

python -S ./bin/pip --version

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

Partage au cas où cela pourrait aider les autres - Dans mon image docker (la base est ubuntu:xenial ), j'ai reçu l'erreur suivante :

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

J'ai changé pip install -U pip && pip install -r /tmp/requirements.txt en pip2 install -U pip && pip2 install -r /tmp/requirements.txt . Cela a résolu le problème.

Je ne sais pas si j'ai vu une réponse / réponse au commentaire de @davidjlloyd :

Je ne suis pas sûr que briser de manière agressive les utilisations existantes d'une fonctionnalité non prise en charge au lieu de déprécier la fonctionnalité pour quelques versions majeures soit la meilleure approche.

Puis-je demander pourquoi il n'y avait pas de processus d'abandon en place pour cela ?
Il semble que cela aurait été assez facile, sur le import de pip , cochez sys.argv[0] ; si ce n'est pas pip ou pipX[.Y] , crachez quelques DeprecationWarning que cela échouera dans la version X+, avec un lien vers ce que vous avez mentionné : https://pip.pypa. io/en/latest/user_guide/#using -pip-from-your-program

Y a-t-il un processus en place pour essayer de s'assurer que ce genre de chose est, espérons-le, évité à l'avenir?

Je ne sais pas si j'ai vu une réponse / réponse au commentaire de @davidjlloyd :

Il a été répondu à plusieurs reprises, peut-être pas sur ce problème spécifique, mais une recherche dans l'outil de suivi des problèmes devrait trouver de nombreuses discussions sur le sujet.

Puis-je demander pourquoi il n'y avait pas de processus d'abandon en place pour cela ?

Parce qu'il n'a jamais été soutenu. Pourquoi avertirions-nous que nous annulons notre soutien à quelque chose que nous n'avons jamais soutenu ? Les gens pensaient qu'il était acceptable de lire le code source de pip et d'utiliser les fonctions qu'ils y trouvaient dans leur propre code. Cela ne l'a jamais été. Nous avons dit qu'il pouvait casser, et dans le pip 10, il l'a fait.

Il semble que cela aurait été assez facile, lors de l'importation de pip, vérifiez sys.argv[0] ; si ce n'est pas pip ou pipX[.Y], cracher quelques DeprecationWarnings

Je ne suis pas sûr que ce soit aussi facile que vous le pensez. Et je dis cela du point de vue de quelqu'un qui a dû faire face à des problèmes où des avertissements ajoutés dans le pip 10 étaient déclenchés alors que nous ne nous attendions pas à ce qu'ils le soient ...

Et encore une fois, il n'est pas nécessaire de déprécier quelque chose qui n'est pas pris en charge en premier lieu.

Y a-t-il un processus en place pour essayer de s'assurer que ce genre de chose est, espérons-le, évité à l'avenir?

Quel genre de chose ? Casse causée par nous changeant des choses pour lesquelles nous ne garantissons pas la rétrocompatibilité ? Non. Nous n'avons pas besoin d'éviter cela. Bien qu'en fait, nous essayons de gérer le processus, par courtoisie envers nos utilisateurs ( pas une obligation !). Dans ce cas, nous avons annoncé le changement 6 mois à l'avance, offert des suggestions aux personnes qui avaient besoin de changer leur code et passé beaucoup de temps depuis la sortie à aider les utilisateurs qui ont eu des problèmes parce que le logiciel sur lequel ils s'appuient n'a pas tenu compte ces avertissements. C'est beaucoup de travail qu'un très petit groupe de bénévoles a déployé pour tenter d'atténuer une situation causée par des personnes qui s'attendent à un soutien qui n'a jamais été offert ou promis. Je vous en prie.

Nous avons mis en place des processus (avertissements d'obsolescence, etc.) pour modifier les éléments pour lesquels nous garantissons la compatibilité - mais l'importation de pip dans votre propre programme n'en fait pas partie.

J'avais un script bash qui installait le flacon et demandait la mise à niveau a cassé mon script, mais je comprends les raisons indiquées ci-dessus. Mon travail pour que mon script continue de fonctionner consistait simplement à lancer un nouveau processus bash, peut-être que c'est faux, mais cela a fonctionné pour moi. Espérons que cela puisse aider les autres avec des scripts similaires.

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

@OneLogicalMyth ce que vous recherchez peut être hash -d pip , voir https://github.com/pypa/pip/issues/5221#issuecomment -381568428.

complètement raté que même après l'avoir lu attentivement, merci @austinbutler cela a résolu mon problème.

La seule raison pour laquelle ce problème a été maintenu ouvert et non fermé en tant que doublon immédiatement était parce que je craignais que pyenv fasse quelque chose avec des cales et que pip ait besoin d'aider d'une manière ou d'une autre. Ce n'était pas le cas, donc ce problème est maintenant clos.

J'ai déjà répertorié les solutions de contournement (toutes triviales) pour presque tous les problèmes mentionnés ici - jetez un œil à https://github.com/pypa/pip/issues/5221#issuecomment -382069604. Espérons que cela réponde à toutes les préoccupations soulevées dans ce numéro. Si ce n'est pas le cas, veuillez ouvrir un nouveau sujet.

@benoit-pierre J'ai ajouté votre suggestion d'utiliser python -m pip au commentaire lié. Merci pour ça. :)

L'installation de pip à l'aide d'easy_install pourrait bien poser des problèmes, et si c'est le cas, nous ne pourrons pas vous aider, car (comme @pradyunsg l' a dit) easy_install est ancien, n'est pas activement maintenu et manque de fonctionnalités récentes.

Merci d'avoir clarifié ma position @pfmoore. C'est de cela que je parlais.

Je suis de plus en plus confus quant aux différents problèmes dont il est question.

Moi aussi.

Juste quelques conseils généraux (à prendre ou à laisser), sur les choses que j'ai vues dans ce numéro :

• Si la commande pip ne fonctionne pas pour une raison quelconque, essayez d'exécuter python -m pip . Il y a de fortes chances python -m pip fonctionne pour vous même si vos scripts wrapper se cassent. Si cela ne fonctionne pas, ouvrez un nouveau sujet.
• N'exécutez pas pip en tant que root ou ne faites pas sudo pip . Vous allez probablement casser votre système et si cela ne suffit pas, vous exécutez du code à distance en tant que root.
• N'utilisez pas easy_install pour les raisons citées en haut de ce commentaire. Voici plus de contexte (qui est légèrement obsolète).
• S'il vous plaît, s'il vous plaît, n'épinglez pas le pip 9. Je crois fermement que cela agit activement pour ralentir la progression de l'emballage Python en général.
  
  
  
  • pip 9 ne prendra jamais en charge PEP 517/518 et rester sur pip 9 signifie que vous devrez prendre la peine de basculer plus tard, lorsqu'un paquet se casse à la dernière minute parce qu'il passe aux nouvelles normes d'emballage.
  
  

Pour résumer, ce n'est probablement pas la faute d'un seul projet/personne et tout le monde est bien motivé pour agir. Oui, votre environnement s'est brisé. Nous comprenons. Ne blâmez pas les personnes qui offrent bénévolement leur temps libre, pour vous aider en ce moment et développer pip.

Vous voulez nous aider ? https://donate.pypi.org est une chose et si ce n'est pas votre genre de chose , il y a beaucoup de problèmes ouverts dans ce traqueur de problèmes pour lesquels vous pouvez nous aider.

Je vais prendre du recul sur ce problème maintenant.

D'accord, une dernière chose, si quelqu'un veut encore discuter de notre décision de déplacer toute notre base de code vers pip._internal , ouvrez un nouveau problème et donnez-moi une mention. Je vais passer un peu de temps à écrire quelque chose avec des liens et tout, sur pourquoi pip a fait ça. De cette façon, @pypa/pip-committers aurait un endroit unique vers lequel les personnes seraient liées sur ce sujet.

Pour le moment, cela a fonctionné sur python3 / pip3 , pour le restaurer

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

@freckletonj S'il vous plaît, ne dites pas aux gens de revenir au pip 9. Ce n'est pas ainsi que vous devriez résoudre ce problème. Il existe de bien meilleures façons.

J'ai lié à un commentaire juste au-dessus du vôtre, énumérant les moyens de résoudre ce problème.

désolé @pradyunsg , mais cela ne fonctionne toujours pas:

$ 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, auquel j'ai lié ci-dessus :

hash -r pip # or hash -d pip

Si quelqu'un a d'autres questions, veuillez ouvrir un nouveau sujet.

5599 fournit des informations et fournit un emplacement unique pour demander de l'aide afin de résoudre ce problème pour les utilisateurs finaux.

La section des commentaires de ce numéro est ouverte aux utilisateurs pour discuter de problèmes et de solutions spécifiques. :)