c'est un problème debian

sur note supplémentaire - remplacer le pip du système par pip est toujours un acte de vandalisme du système où celui qui l'inflige est responsable des retombées

Je vous suggère d'attendre une copie appropriée de pip 10 de Debian - comme le dit @RonnyPfannschmidt , vous ne devriez pas utiliser pip pour mettre à niveau vos packages système ...

On dirait que le script Debian pip3 utilise les composants internes de pip, donc obtenir un correctif compatible pip10 leur appartient définitivement (et je m'attendrais à ce qu'ils attendent de publier leur paquet pip10 jusqu'à ce qu'ils l'aient trié).

sur note supplémentaire - remplacer le pip du système par pip est toujours un acte de vandalisme du système où celui qui l'inflige est responsable des retombées

Convaincre les utilisateurs de Debian/ubuntu de ne pas vendre, puis de laisser pourrir la moitié de leurs paquets, et ce serait un argument valable.

Vous pouvez utiliser virtualenv ou venv pour vous isoler de l'installation du système pip.

Vous ne devriez pas modifier les fichiers gérés par le gestionnaire de paquets (ici l'installation du système pip) -- je pense qu'ils ne s'attendent pas à ce que les utilisateurs modifient les choses -- ce n'est probablement pas pris en charge par Debian. Cela causera forcément des problèmes comme celui-ci.

Même problème sur Fedora aussi.

Peut-être qu'il devrait y avoir un canal "bêta", ou un mécanisme similaire pour que les gens fassent plus de tests avant la sortie, plutôt que de simplement vider une version cassée sur pypi et de faire exploser les versions de tout le monde.

@fake-name Deux pré-versions ont été réalisées :

• 10.0.0b1 est sorti le 31 mars
• 10.0.0b2 est sorti le 2 avril

@fake-name en outre, la suggestion générale d'utilisation sur toutes les distributions est - utilisez un virtualenv, ne vandalisez pas le système, et cela fonctionne - les gens le suivent et se demandent ensuite quand les choses se cassent et blâment le pip

il y a eu beaucoup de tests manuels et automatisés avec virtualenvs qui fonctionnent

aussi dans un virtualenv au moins il ne devrait pas y avoir de commande pip3 faite par debian - alors de quoi diable parlez-vous par rapport à cette rupture dans virtualenvs - veuillez fournir suffisamment de données pour vérifier réellement au lieu de pleurnicher sur les ruptures sans fournir les données nécessaires pour les vérifier

pip est motivé par des bénévoles, pas une entreprise avec des dizaines d'employés

~Supprimé~. confondait cela avec https://github.com/pypa/pip/issues/5220

Je suis un derp.

Merci, je n'avais pas réalisé que remplacer le pip système était une mauvaise idée, mais cela a du sens. Cependant, ce serait une bonne expérience utilisateur si pip ne voulait pas mettre à niveau dans ce cas. Cela serait-il possible? Je pense que beaucoup de gens (y compris moi) feraient tout ce que "la chose" leur demande de faire.

@fake-name merci pour le suivi - il est étonnamment courant de ne pas correspondre au problème de détail lorsqu'une version majeure a un impact à multiples facettes et qu'une partie essaie de vous gâcher la journée

ce serait une bonne expérience utilisateur si pip ne voulait pas insister sur la mise à niveau dans ce cas

Les fournisseurs de distribution pourraient certainement corriger pip pour supprimer cet avertissement (ou mieux, le remplacer par une vérification similaire par rapport aux packages système) avec les autres correctifs qu'ils créent. Je ne sais pas comment le pip de base pourrait détecter qu'il s'exécute à partir d'une installation packagée par le système sans la coopération de la distribution, mais s'il existe un moyen de le faire, c'est quelque chose que nous pourrions envisager (mais sachez que d'après mon expérience, nous obtenons comme beaucoup de retours négatifs du fait de se tromper sur de telles heuristiques comme nous le faisons de ne pas du tout inclure d'heuristiques...)

Préférez toujours "python3 -m pip" à pip3" ou encore mieux "/usr/bin/env python3 -m pip" c'est plus sûr et permet d'éviter ce problème avec pip10

Nous avons résolu ce problème par un hachage clair dans bash :

$ hash -d pip

Ou en tiret (sh) :

$ hash -r pip

Répondez également à ce problème lors de la création d'images Docker.

@RonnyPfannschmidt dit que "le remplacement du pip du système par le pip est toujours un acte de vandalisme du système où celui qui l'inflige est responsable des retombées", qui a 6 pouces levés. Je trouve que c'est un commentaire particulièrement obtus étant donné que j'ai demandé de le faire par pip lui-même :

_Vous utilisez pip version 8.1.1, cependant la version 10.0.0 est disponible.
Vous devriez envisager de mettre à niveau via la commande 'pip install --upgrade pip'._

S'il y a une certaine validité à ce commentaire, alors les créateurs de pip devraient supprimer ce message et j'encouragerais @RonnyPfannschmidt à soulever un problème à cet effet et à

@qacollective - Je pense que l'argument ici est que les distributions ont pris le pip, l'ont modifié et l'ont reconditionné dans leurs référentiels. En tant que tel, ce n'est pas vraiment la faute de Pypi si le message est toujours là.

La plupart de cela est parce qu'un tas de distros vraiment essayer vraiment difficile de tout remballer dans leurs propres dépôts de paquets. La plupart du temps, les choses sont ensuite laissées à pourrir.

Personnellement, au moins pour Python sur Ubuntu, j'aimerais qu'ils le quittent. La version de pratiquement tous les packages python dans apt va de vraiment très ancienne à fossilisée. Apt est fondamentalement inutile pour python, à mon humble avis.

FWIW, j'ai tendance à trouver que la meilleure option est de ne jamais installer le pip de distribution en premier lieu, mais plutôt de l'installer manuellement via get-pip.py . De cette façon, vous n'avez pas de problèmes avec le gestionnaire de packages de plate-forme qui ne connaît que certains des packages python.

Utilisez toujours --user pour éviter de tuer votre système

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

Devrait gérer la plupart des cas de bogue et entraîner l'installation de la bonne version de pip dans ˜/.local/bin .

Je peux confirmer que la solution de

Un peu de contexte : après la mise à niveau (pip install -U pip) sur un vanilla ubuntu 16.04 (AWS AMI), on arrive à la situation suivante :
$CHEMIN=..:/usr/local/ bin:... :/usr/ bin:...
/usr/bin/pip est toujours l'ancienne version/'oem' (cassé)
/usr/local/bin/pip est le nouveau script v10 (fonctionne bien lorsqu'il est invoqué directement)

Même si la version appropriée de pip précède la version cassée dans le PATH, bash se souvient toujours de l'ancienne, donc lorsque vous l'invoquez en tant que "pip", vous obtiendrez l'ancienne version cassée en cours d'exécution. hash-d pip ou hash -r résout le problème.

Tout d'abord, quelques notes sur ce qui s'est passé ici sur Debian/Ubuntu (et probablement quelques autres distributions Linux) :

• pip ne prend pas en charge l'utilisation de ses composants internes en les important. Plus d'informations à ce sujet dans la documentation ici .
• Debian (d'où Ubuntu) ne prend pas en charge la modification des fichiers gérés par leur gestionnaire de paquets en utilisant quelque chose, ce n'est pas leur gestionnaire de paquets.

Ce problème est causé par, eh bien, les deux étant violés d'une certaine manière.

• Debian utilise les méthodes internes de pip (qui ne fonctionnent plus en raison d'une réorganisation des internes de pip). Debian suppose ici que la version pip dans leurs référentiels est celle qui serait installée.
• L'exécution de pip install --upgrade pip , en tant que root, sans aucun autre paramètre modifie les fichiers qui sont censés être gérés par apt, ce qui casse le script de Debian.

Quelques conseils généraux sur Linux :

• C'est une bonne habitude d'utiliser --user dehors d'un venv.

  pip install --upgrade --user pip
  

• Ne lancez

Quelle est la solution de contournement ?

La solution de @standag est utile lorsque cela est causé par la mise en cache des exécutables par bash.

hash -r pip # or hash -d pip

Si vous avez modifié l'installation de pip du gestionnaire de packages de votre système d'exploitation (par exemple en utilisant sudo pip ) et que python -m pip fonctionne toujours, une solution consiste à désinstaller la version installée de pip et à réinstaller la version installée du gestionnaire de packages. .

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

Si vous n'êtes pas sur Debian/Ubuntu _and_ pip s'est cassé pour vous, essayez d'exécuter :

python -m pip install --force-reinstall pip

Si ce qui précède ne résout pas vos problèmes, veuillez déposer un nouveau problème.

[édité par @pradyunsg : le rendre plus pertinent pour relier tout le monde ayant des problèmes similaires à ce commentaire ; mettre à jour la suggestion pour inclure la désinstallation/réinstallation de la solution de contournement]

Et si vous le résolviez en dehors de Docker ? C'est cassé dans mon système habituel et la commande de hachage n'a pas reconnu pip.
thinkdigital@thinkdigital-HP-Spectre-x360-Convertible:~$ hash -d pip bash: hash: pip: not found

J'ai trouvé pip3, la version 9.0.1 installée dans un virtualenv à partir d'un projet et je l'ai copié dans mon /usr/bin et cela fonctionne à nouveau. Voici le contenu de l'exécutable pip3 pour ceux qui voudraient aussi le réparer eux-mêmes.

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

from pip import main

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

Je suis sûr que tout ce que vous avez à faire est de l'enregistrer dans un fichier appelé pip3, rendez-le exécutable en exécutant sudo chmod +x ./pip3, exécutez sudo apt remove python3-pip, puis copiez-le dans le répertoire bin en exécutant sudo cp ./pip3 /usr/bin.
Voici le fichier brut pour ceux qui veulent juste le télécharger et le déplacer.
pip3.zip

Ça marche pour moi:
boucle https://bootstrap.pypa.io/get-pip.py | python sudo

Je suis désolé, mais je voudrais souligner que l'exécution de code python curl'd à partir d'un site Web avec un accès root est tout simplement terriblement peu sûre.

D'accord, et je dois souligner qu'il ne s'agit pas get-pip, ni même pip lui-même via sudo.

Dans ce cas, la version du gestionnaire de packages système ne fonctionne pas. Même
après la purge et la réinstallation.

Le jeu. 19 avril 2018, 01h53, Paul Moore [email protected] a écrit :

D'accord, et je dois souligner que ce n'est pas un pip officiel
recommandation. Comme cela a été dit à plusieurs reprises, vous devriez utiliser
votre gestionnaire de packages système pour mettre à jour ou gérer votre système pip
installation, pas get-pip, ni même pip lui-même via sudo.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pip/issues/5221#issuecomment-382660881 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AV-Hfecz8l1NEyq3vsih0DpNP7QYdxuvks5tqFCdgaJpZM4TVEq6
.

Si la réinstallation du package système ne fonctionne toujours pas, vérifiez si vous avez pip10 quelque part dans /usr/local/ et supprimez tout le dossier.

Remplacer celui de /usr/bin a fonctionné pour moi même si je PENSE que c'est
celui que le gestionnaire de packages système installait.

[ @pradyunsg a coupé le contenu de l'e-mail]

@ThinkDigitalRepair Les éléments suivants sont-ils utiles ?

Dans d'autres cas, vous souhaiterez transmettre --user lors de l'installation/mise à niveau des packages. TBH, sous Linux, c'est une bonne habitude d'utiliser --user .

pip install --upgrade --user pip

D'accord. Merci. J'ai tout foiré en suivant un didacticiel Jupyter Notebook de leur
site qui vous dit de mettre à jour pip directement. Copier et coller sans
sachant que les conséquences frappe à nouveau. :(

[ @pradyunsg a coupé le contenu de l'e-mail]

@ThinkDigitalRepair pip 10, espérons-le, améliorera les choses - il imprime de meilleurs messages d'erreur au lieu d'une longue PermissionError lorsque cela se produit.

Clôturer ce problème maintenant car il n'y a rien d'actionnable ici de la part de pip.

Si vous cherchez comment résoudre/contourner ce problème, veuillez consulter https://github.com/pypa/pip/issues/5221#issuecomment -382069604.

@pradyunsg dans de nombreux cas, les solutions données dans ce commentaire ne fonctionneront pas. Sous un nouveau Ubuntu 17.10, exécutez pip install --upgrade pip : après cela, la commande pip sera interrompue et les solutions du commentaire ne le résoudront pas. Et ils ne devraient pas !

Avoir un système pip 9 installé avec un utilisateur installé pip 10, oblige le script système pip à essayer d'importer main() à partir de l'utilisateur pip 10, avec un chemin d'importation incorrect. Hash -r ou -d ne résoudra pas cela car la commande pip exécutera toujours le pip système par défaut. Et ni l'un ni l'autre ne résoudra le problème en mettant à niveau le pip utilisateur, car le pip système sera toujours de 9, le pip utilisateur sera toujours de 10, donc l'importation continuera à échouer.

La solution pour ces cas doit être la désinstallation de l'un des deux pépins.

• python -m pip uninstall pip --user , en gardant le pip système, qui est plus ancien

ou

• sudo apt remove python-pip et conservez le pip installé par l'utilisateur, qui ne sera pas accessible en exécutant pip dans le terminal par défaut. Vous devrez soit l'exécuter avec python -m pip , soit ajouter les chemins à votre var env PATH, etc.

Tout cela s'applique aux deux, pip sous python 2 et 3.

Sur tous mes systèmes Ubuntu (16.04, 17.10. 18.04), j'ai le système pip à l'ancienne version et l'utilisateur est avec pip 10 et je ne vois jamais votre erreur d'importation.
Êtes-vous sûr de ne pas avoir de pip système corrompu ?

@gsemet vous avez probablement ajouté ~/.local/bin à votre var env PATH (ou peut-être en utilisant un shell différent et plus intelligent que le bash par défaut), donc lorsque vous exécutez pip il utilise le script pip 10 installé par l'utilisateur, et non le script pip 9 installé par le système. Dans Ubuntu, ce n'est pas comme ça par défaut. Cela peut être fait, bien sûr, et j'aimerais que cela vienne comme ça par défaut. Mais par défaut, la commande pip appellera le pip installé sur le système, même si un utilisateur en a installé un.

Comment reproduire cela sous une nouvelle installation d'Ubuntu 17.10, y compris la preuve que les commandes du commentaire 5221 ne parviennent pas à le réparer, et ce que j'ai proposé le résout.

Installation des deux pips (système et utilisateur), ce qui interrompt la commande pip :

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

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

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

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

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

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

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

Comme vous pouvez le voir, la commande pip pointe vers le pip système par défaut, pas celui installé par l'utilisateur.

Commandes du commentaire référencé, preuve qu'elles ne résolvent pas le problème :

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

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

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

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

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

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

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

Comme vous pouvez le voir, tant que les deux pips sont installés et que la commande pip pointe vers le pip système (comportement par défaut dans Ubuntu), le problème persistera.

Correction de l'option 1 :

Supprimez le pip système, conservez le pip utilisateur, qui par défaut n'est pas accessible via la commande pip (vous devez donc utiliser python -m pip ).

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

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

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

Vous pouvez ajouter ~/.local/bin à votre var env PATH, pour pouvoir utiliser la commande pip avec le pip utilisateur.

Correction de l'option 2 :

Supprimez le pip utilisateur, conservez le pip système, qui est plus ancien mais a par défaut une commande pip dans le chemin.

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

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

@fisadev Bien sûr, cela est nécessaire pour prendre en charge le package 'pip install --user' installable par l'utilisateur. Mais je pense qu'il devrait être dit aux utilisateurs "si vous voulez forcer la mise à jour du pip 10 avant que le paquet debian/ubuntu ne soit mis à jour, vous devez utiliser pip install --user --upgrade pip et vous assurer que $HOME/.local/bin est dans votre chemin C'est simple à faire.

@gsemet Je suis d'accord, les utilisateurs doivent être informés de l'exigence de chemin. Cela n'est pas mentionné dans le commentaire référencé à partir d'autres threads comme solution, et dans un cas, la discussion a été verrouillée même après qu'un utilisateur a dit qu'il avait exécuté ces commandes et que cela n'avait pas résolu le problème :/

@fisadev Merci beaucoup. Fix option1 aide vraiment.

@RonnyPfannschmidt

remplacer le pip du système par pip est toujours un acte de vandalisme du système où celui qui l'inflige est responsable des retombées

est un commentaire de vandalisme mental. Comme si la personne effectuant la mise à niveau (naïve) envisageait intentionnellement d'endommager sa propre installation... Si tel était le cas, alors pip lui-même ne devrait pas inciter l'utilisateur à passer de 9.0.1 à 10.0.1 à chaque commande pip unique exécutée. J'ai moi-même suivi cette recommandation et je me suis retrouvé dans ce pétrin.

Heureusement:
sudo python -m pip install pip==9.0.1
était un remède assez facile.

Blâmer la victime n'est pas une réponse, cependant.

Salut @rod-app !

Si tel était le cas, alors pip lui-même ne devrait pas inciter l'utilisateur à passer de 9.0.1 à 10.0.1 avec chaque commande pip exécutée.

Nous l'avons remarqué et avons travaillé avec les fournisseurs de systèmes d'exploitation pour éviter cela dans les futures versions de pip. -- #5346.

Pour résoudre le problème, j'ai couru...

sudo geany -i /usr/bin/pip

... et modifié le fichier /usr/bin/pip fourni par Debian pour le remplacer par...

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

et l'équivalent pour /usr/bin/pip3 (notez que cela appelle python3 à la place).

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

...qui ramène toutes les fonctionnalités de pip malgré la version 10 installée dans mon site-packages. Je suppose que cela durera exactement le temps que Debian prendra pour le réparer (ou le re-casser) en envoyant un paquet python-pip mis à jour. Pourquoi ils n'ont pas utilisé le package main en premier lieu, je ne sais pas.

Version officielle

La version de pip installée dans .local/bin/pip montrée ci-dessous est un peu plus sophistiquée et inclut une substitution pour supprimer les extensions -script, .py, .pyw et .exe des arguments passés, mais je ne sais pas ce que cela fait ou pourquoi j'en ai besoin alors je l'ai laissé comme ci-dessus pour plus de simplicité.

#!/usr/bin/python

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

from pip._internal import main

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

J'ai trouvé une cause non liée à ce problème pip v10. Lors de la mise à niveau de pip à l'aide d'un très ancien système pip (v1.5.6 sur Debian Jessie, c'est-à-dire oldstable) pour lequel --system est la valeur par défaut, j'ai remarqué que des scripts /usr/local/bin/pip contenant from pip import main -- que j'ai trouvé en regardant les fichiers. Je suppose que c'est parce que l'ancien pip (ou peut-être les packages d'installation qu'il utilise) n'installe pas correctement le fichier .whl.

python -m pip install --force-reinstall pip corrigé cela.

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. :)