Voici le résultat de pip3 :

werner in ~ at octopus23
➜ pip3 install pipenv
Collecting pipenv
  Using cached https://files.pythonhosted.org/packages/2c/01/37a5867a47d52856b077d0faa561b791cb6e6e3e9410837b6d62f569c1e6/pipenv-11.10.1-py3-none-any.whl
Collecting virtualenv (from pipenv)
  Using cached https://files.pythonhosted.org/packages/ed/ea/e20b5cbebf45d3096e8138ab74eda139595d827677f38e9dd543e6015bdf/virtualenv-15.2.0-py2.py3-none-any.whl
Collecting pip>=9.0.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Collecting setuptools>=36.2.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/8c/10/79282747f9169f21c053c562a0baa21815a8c7879be97abd930dbcf862e8/setuptools-39.1.0-py2.py3-none-any.whl
Collecting virtualenv-clone>=0.2.5 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/6d/c2/dccb5ccf599e0c5d1eea6acbd058af7a71384f9740179db67a9182a24798/virtualenv_clone-0.3.0-py2.py3-none-any.whl
Collecting certifi (from pipenv)
  Using cached https://files.pythonhosted.org/packages/7c/e6/92ad559b7192d846975fc916b65f667c7b8c3a32bea7372340bfe9a15fa5/certifi-2018.4.16-py2.py3-none-any.whl
Installing collected packages: virtualenv, pip, setuptools, virtualenv-clone, certifi, pipenv
Successfully installed certifi-2018.4.16 pip-10.0.1 pipenv-11.10.1 setuptools-39.1.0 virtualenv-15.2.0 virtualenv-clone-0.3.0

Je suppose que c'est probablement une conséquence de Pipenv en fonction de pip, mais je ne sais pas si Pipenv devrait être responsable de cela. Peut-être que Debian devrait le faire car ce sont eux qui ont rompu le couplage Python-pip. Pipenv n'est certainement pas le seul package qui dépend de pip non plus, mais je ne sais pas quelle est la meilleure pratique ici.

@ncoghlan pourriez-vous donner un aperçu sur ce sujet ? Spécifiquement

1. Un package doit-il dépendre de pip ?
2. Si 1. est oui, devrait-il être responsable de ce type de conflit avec le gestionnaire de paquets système ?
3. Si 2. est oui, comment ?
4. Si 2. est non, qui devrait être responsable ? L'utilisateur doit-il être invité à utiliser une solution de contournement à la place ?

Dans tous les cas, vous ne devriez probablement sudo pip install quoi Vous devriez faire l'une des actions suivantes à la place

• Utilisez APT jusqu'au bout
• pip install --user
• Un gestionnaire personnalisé tel que pipsi

Ou encore mieux, évitez complètement le système Python et utilisez plutôt pyenv ou d'autres gestionnaires d'exécution Python.

Grattez-les. Évitez Python d'APT, point final.

vous ne devriez probablement jamais sudo pip installer quoi que ce soit sur Ubuntu de toute façon

En fait, je ne l'ai jamais fait. Je suis conscient des problèmes liés à l'utilisation de sudo pip sous Ubuntu, j'utilise donc apt chaque fois que cela est possible ou je m'en tiens à --user .

Ah je vois le problème maintenant. Les modules utilisateur ont la priorité sur ceux du système, mais /usr/bin est avant $HOME/.local/bin en vous PATH . /usr/bin/python essaie d'importer l'installation du système pip (qui est toujours 9.x), mais a fini par trouver l'installation de l'utilisateur (qui est 10.x). Quel bordel.

2095 est le même, mais je veux garder cela ouvert car je pense qu'il devrait y avoir une solution plus robuste que de dépendre du fait que l'utilisateur ait un PATH convivial.

c'est assez stable quand l'utilisateur a :

• ˜/.local/bin au début du PATH . Devrait être la valeur par défaut sur Ubuntu, depuis 16.10 . C'est une bonne pratique de l'avoir car il permet pip install --user comportement
• l'utilisateur doit toujours utiliser pip install --user . Jouer avec le pip du système est vraiment mauvais dans chaque distribution, même les dossiers étranges "dist-packages/site-packages" dans Debian ne protègent pas contre les erreurs de l'utilisateur.

Nous avons assuré ce comportement dans toutes nos installations d'utilisateurs d'ubuntu (organisation de plus de 1000 installations de différentes versions d'ubuntu), et la transition vers pip10 a fonctionné à merveille.

Bien que je convienne que python et son écosystème sont compliqués et qu'il serait préférable que les gens n'aient pas à configurer correctement leurs chemins pour obtenir le bon ordre de recherche, ce n'est malheureusement qu'un fait sur la façon dont l'installation fonctionne actuellement dans les gestionnaires de paquets et ce n'est pas exactement un problème pipenv en soi. Je ne pense pas que nous puissions faire grand-chose pour y faire face de manière indépendante, c'est plus un problème à résoudre sur les listes de diffusion python

Ah, je vois maintenant quel est le problème, merci. Je n'ai jamais pensé que le chemin pouvait influencer cela, c'est pourquoi il ne m'est pas venu à l'esprit de l'inclure dans la description du problème. Désolé pour ça, et merci pour votre aide.

Ce qui a résolu le problème pour moi était d'ajouter

export PATH="${HOME}/.local/bin:$PATH"

au profil.

Edit : assurez-vous d'exécuter hash -r ou entrez un nouveau shell pour que cette modification prenne effet.

Je ne pense pas que nous puissions faire grand-chose pour y faire face de manière indépendante

Peut-être qu'il pourrait y avoir des instructions d'installation plus détaillées ou des mises en garde ? Je ne connais pas trop le fonctionnement de pip, mais j'ai peut-être lu une note sur les problèmes de chemin. Mais je suppose que l'écosystème des différents gestionnaires de paquets et distributions est trop complexe pour une règle simple…

@slhck c'est en fait tellement frustrant qu'il y ait eu ce xkcd spécifiquement sur les environnements python et les installations sudo et gestionnaire de paquets il y a quelques jours

Voici un bon guide étape par étape que j'ai utilisé avec succès sur Ubuntu 18.04 :
https://phoikoi.io/2018/04/03/bootstrap-pipenv-debian.html

Il y a aussi https://github.com/pypa/python-packaging-user-guide/issues/396 , qui discute de la question de savoir si nous pourrions ou non proposer la liste de contrôle ou le script de dépannage pour aider les gens à identifier et résoudre les problèmes potentiels dans leur environnement. Je ferai une note sur le potentiel de conflits de commandes PATH / sys.path .

Merci @slhck . Votre solution de contournement d'exportation m'a fait gagner le plus de temps ; Je l'ai ajouté à /etc/profile.

C'est vraiment stupide que nous ayons 2 niveaux d'empaquetage de logiciels sur Linux. Pire encore, avec la dernière version du *buntus, les deux saveurs de l'un d'eux (pip/pip3) sont cassées.

Je l'ai écrit sur Launchpad : https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1772746

@texadactyl Debian a cette politique (j'oublie ce que c'est) selon laquelle pip ne doit pas être installé par défaut, et ils s'y sont tenus avec beaucoup de plaintes précédentes. La tradition repose profondément, profondément dans les racines de Debian. Je serais très heureux s'ils pouvaient repenser cela, mais je doute fortement qu'ils le fassent.

J'étais confronté au même problème sur Ubuntu 18 et Python 3.6

Ci-dessous les étapes que j'ai suivies :

1) Premièrement, je recevais l'erreur :

Traceback (appel le plus récent en dernier) :
Fichier "/usr/bin/pip", ligne 9, dans
de l'importation principale de pip
ImportError : impossible d'importer le nom principal

2) J'ai modifié le fichier /user/bin/pip en :

importer le système
de pip._internal importer le principal en tant que _main
if __name__ == '__main__' :
sys.exit(main())

3) Ensuite, il a commencé à me donner cette erreur :

Traceback (appel le plus récent en dernier) :
Fichier "/usr/bin/pip3", ligne 11, dans
sys.exit(main())
NameError : le nom 'main' n'est pas défini

4) J'ai modifié /usr/bin/pip3 en :

importer le système
de pip._internal importer le principal en tant que _main
if __name__ == '__main__' :
sys.exit(_main())

5) Ensuite, j'ai commencé à obtenir l'erreur :

Traceback (appel le plus récent en dernier) :
Fichier "/usr/bin/pip3", ligne 11, dans
sys.exit(main())
NameError : le nom 'main' n'est pas défini

6) J'ai renommé main() en _main(), et le tour est joué .. ça a marché !!! :) :)

Bien que cela ait peut-être résolu le problème pour vous, c'est un très mauvais conseil. Vous ne devez pas modifier manuellement les fichiers système. S'il vous plaît jeter un oeil à mon commentaire précédent pour une solution.

edit: la solution de @slhck l'a résolu. Besoin d'avoir ~/.local/bin dans votre chemin

Obtenir le même problème sur Ubuntu 16.04.

$ sudo apt install python3-pip
$ pip3 --version
pip 8.1.1 from /usr/lib/python3/dist-packages (python 3.5)
$ python3 -m pip install --user pipenv
$ pip3 --version
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

# revert back and fix pip
$ sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

Je veux juste ajouter que je suis également tombé sur ce problème. J'avais déjà ~/.local/bin comme première chose sur mon chemin. Le problème est de savoir comment bash hache les commandes. La solution à ce problème a été trouvée ici : https://github.com/pypa/pip/issues/5221#issuecomment -381568428

@thernstig Oui, c'est correct - j'ai ajouté la commande hash -r nécessaire à ma solution ci-dessus, que j'ai oublié de mentionner explicitement.

@slhck Pas de problème, content d'avoir pu aider

J'ai réalisé que le problème était clos, mais je publie dans l'espoir que cela puisse aider à éviter les modifications de PATH. J'ai rencontré cela aujourd'hui lors de la configuration d'une nouvelle machine Ubuntu 18.04 et j'ai pu le résoudre sans modifications de PATH, bien que j'aie redémarré (je suis à peu près certain que la déconnexion/connexion fonctionnera, mais je n'ai pas vérifié).

Après avoir installé pip3 via python3-pip et pipenv avec pip3 install --user pipenv j'ai reçu l'erreur de sujet. J'étais sur le point d'utiliser la solution de contournement de @slhck lorsque j'ai remarqué ce qui suit dans ~/.profile (stock, je n'ai aucune modification):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Curieux, j'ai redémarré et bien sûr, le problème a été résolu car mon .local/bin était maintenant au début de mon PATH et pip3 fonctionnait à nouveau.

@jlitzingerdev Je suis à peu près sûr que le chemin est le chemin par défaut, c'est juste que pour mon système, puisque j'utilisais un shell et un profil différents, je l'ai supprimé ou construit à partir de zéro, d'où ma "solution de contournement" qui n'aurait pas dû être nécessaire en premier lieu. Heureux que vous l'ayez compris.

@slhck C'est le cas, mais il se peut qu'il ne soit pas dans PATH lors de la première connexion car ~/.local/bin n'existe peut-être pas, ou c'était mon cas particulier.

Qu'avons nous à faire?

Je veux juste vous remercier d'avoir inclus les commandes de restauration, j'avais du mal à faire fonctionner à nouveau pip.

Je souhaite installer pipenv sous Ubuntu 18.04. Quand je le fais, il casse pip / pip3.

Résultat attendu

Version installée et fonctionnelle de pipenv.

Résultat actuel

pip / pip3 sont cassés, selon que je souhaite installer pipenv via pip ou pip3.

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

Étapes à reproduire

1. Set up Ubuntu 18.04

2. Run `pip install pipenv` or `pip3 install pipenv`

3. Run `pip` or `pip3` – the error is printed, and pip / pip3 do not work anymore.

Afin de résoudre le problème, je dois exécuter:

sudo python -m pip uninstall pip && sudo apt install python-pip --reinstall
sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

Mais je ne peux pas installer pipenv en utilisant pip. L'installation via apt ne fonctionne pas car aucun PPA n'est disponible.

j'ai 3 pip dans mon ubuntu 18 pip, pip3 et pip3.6 pip est pour 2.7 pip3 est pour 3.5 et pip3.6 pour 3.6 maintenant quel pip montre l'emplacement du fichier dans .local/bin . J'ai supprimé les fichiers pip et pip3 d'ici. maintenant quel pip3 me montre le /usr/bin/pip3. exécutez la commande sudo nano /usr/bin/pip3 remplacez la première ligne de l'interpréteur par !#/usr/bin/python3 par #/usr/bin/python3.5. travaille pour moi. tous mes pépins fonctionnent. J'espère que ça aide

j'ai 3 pip dans mon ubuntu 18 pip, pip3 et pip3.6 pip est pour 2.7 pip3 est pour 3.5 et pip3.6 pour 3.6 maintenant quel pip montre l'emplacement du fichier dans .local/bin . J'ai supprimé les fichiers pip et pip3 d'ici. maintenant quel pip3 me montre le /usr/bin/pip3. exécutez la commande sudo nano /usr/bin/pip3 remplacez la première ligne de l'interpréteur par !#/usr/bin/python3 par #/usr/bin/python3.5. travaille pour moi. tous mes pépins fonctionnent. J'espère que ça aide

Toutes ces étapes ne sont vraiment pas encouragées. Vous ne devez pas modifier manuellement les fichiers dans /usr/bin . Au lieu de cela, essayez de désinstaller pip comme mentionné ci-dessus et réinstallez via apt . Cela devrait vous permettre d'obtenir les installations système correctes. Si vous rencontrez ensuite des problèmes avec pipenv , veuillez ouvrir un nouveau problème et décrire votre problème plutôt que d'essayer de telles solutions.

la réinstallation via apt comme mentionné ci-dessus ne changera rien car elle génère la même sortie. Il indique simplement qu'il ne peut pas importer le nom principal et que lors de l'importation de pip dans un interpréteur python, il l'importe en tant que module , cela signifie que le nom principal n'est pas disponible dans le module où il essaie de rechercher. Maintenant, je n'ai pas suggéré de modifier aveuglément ci-dessus. En tant qu'amateur de logiciels, lorsque j'étais sur ubuntu14, j'ai vérifié le fichier pip et il a le même code que celui d'ubuntu18 pip3 . alors qu'est-ce qui a changé. La version python fournie avec celui-ci l'a fait.

Parce que pip pour python3.5 et 2.7 n'a que main défini dans le module pip.
Et python3.6 l'a défini dans pip._internal

Maintenant, les deux déclarations ci-dessus résolvent le problème de tout le monde

le problème réside dans l'interprète lui-même utilisé

python3; mais à quel python fait-il référence
Les développeurs qui n'avaient que python 2.7 et sont passés à ubuntu18 auront probablement python 3 en tant que python3.6

mais qu'en est-il de ceux qui avaient installé python3.4 pr 3.5. D'abord le python3 référencé à python3.5 et maintenant après la mise à niveau, il fera référence à python3.6

Donc, la façon dont cela a été géré par Debian l'a cassé

le simple fait d'indiquer le bon interprète résoudra le problème
des deux ayant des erreurs

de l'importation principale de pip
et
de pip._internal importer le principal en tant que _main

Merci
ps
À ce stade, je dois dire que donner des cours sur ce qu'il ne faut pas sera ok sur d'autres plateformes, mais sur github où d'autres développeurs passionnés viennent résoudre leurs problèmes ; surtout quand ils essaient d'exécuter beaucoup de commandes ou de modifier des fichiers de configuration pour le faire fonctionner, je dois dire ne pas être si intelligent que vous commencez à décourager les gens comme ça.

REMARQUE : les nouvelles versions ne fonctionneront pas si elles ne modifient pas le code. Ils ajouteront des solutions de contournement pour que tout le monde le désinstalle et l'installe

J'espère qu'à ce stade vous l'aurez. Paix et ne me dérange plus

@ r-tron18 Je suis désolé que vous vous sentiez sermonné par ce qui était censé être une suggestion constructive - ne pas vous faire modifier un fichier système. D'après le peu de contexte que vous avez donné dans votre message d'origine, il était impossible de dire si vous êtes un utilisateur expérimenté qui sait ce qu'il fait, ou si vous appliquez simplement des solutions de contournement qu'il aurait pu trouver ailleurs. Je passe beaucoup de temps sur divers sites Web de dépannage et de questions-réponses, et je suppose que vous conviendrez que nous ne devrions pas encourager les utilisateurs à essayer des correctifs aléatoires ou à sudo -modifier un fichier fourni par le système, ce qui conduit souvent à plus erreurs et confusions. C'est plus un problème général.

Je ne suis toujours pas convaincu que ce que vous proposez soit une solution fiable. Et : nous pouvons avoir une discussion civile sur les mérites de cette solution - GitHub est un endroit où je suis autorisé à exprimer cela.

La raison en est : changer le shebang de /usr/bin/pip3 en #!/usr/bin/python3.5 ne fera que vous coincer avec cette version. Il devrait lire #!/usr/bin/python3 , et cela devrait être un lien symbolique vers /usr/bin/python3.6 (ou tout ce qui est en cours sur votre système). Toute mise à niveau de Python modifiera probablement ce fichier de toute façon.

Vous dites:

mais qu'en est-il de ceux qui avaient installé python3.4 pr 3.5. D'abord le python3 référencé à python3.5 et maintenant après la mise à niveau, il fera référence à python3.6
Donc, la façon dont cela a été géré par Debian l'a cassé

Êtes-vous en train de dire qu'après une mise à niveau de Python 3.5 vers Python 3.6, ce lien symbolique python3 n'a pas été mis à jour ? Si ce que vous observez est bien un bogue avec Debian ou Ubuntu, où une mise à jour Python n'a pas réussi à définir les liens symboliques corrects, alors ce bogue devrait probablement être corrigé en amont, non ?

J'ai réalisé que le problème était clos, mais je publie dans l'espoir que cela puisse aider à éviter les modifications de PATH. J'ai rencontré cela aujourd'hui lors de la configuration d'une nouvelle machine Ubuntu 18.04 et j'ai pu le résoudre sans modifications de PATH, bien que j'aie redémarré (je suis à peu près certain que la déconnexion/connexion fonctionnera, mais je n'ai pas vérifié).

Après avoir installé pip3 via python3-pip et pipenv avec pip3 install --user pipenv j'ai reçu l'erreur de sujet. J'étais sur le point d'utiliser la solution de contournement de @slhck lorsque j'ai remarqué ce qui suit dans ~/.profile (stock, je n'ai aucune modification):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Curieux, j'ai redémarré et bien sûr, le problème a été résolu car mon .local/bin était maintenant au début de mon PATH et pip3 fonctionnait à nouveau.

Cela fonctionne pour moi, après le redémarrage, tout fonctionne bien. (après l'installation : "pip3 install --user pipenv" redémarrez votre système et cela fonctionnera.