eso es un problema de Debian

en una nota adicional: reemplazar el sistema pip usando pip es siempre un acto de vandalismo del sistema en el que el que lo inflige es responsable de las consecuencias

Le sugiero que espere una copia adecuada empaquetada de pip 10 de Debian; como dice @RonnyPfannschmidt , no debería usar pip para actualizar los paquetes de su sistema ...

Parece que el script de Debian pip3 usa los componentes internos de pip, por lo que obtener una solución compatible con pip10 definitivamente depende de ellos (y espero que esperen a lanzar su paquete pip10 hasta que lo hayan resuelto).

en una nota adicional: reemplazar el sistema pip usando pip es siempre un acto de vandalismo del sistema en el que el que lo inflige es responsable de las consecuencias

Convencer a la gente de debian / ubuntu de no vender y luego dejar que se pudran la mitad de sus paquetes, y ese sería un argumento válido.

Puede utilizar virtualenv o venv para aislarse de la instalación de pip del sistema.

No debería modificar los archivos administrados por el administrador de paquetes (aquí, la instalación de pip del sistema); creo que no esperan que los usuarios modifiquen las cosas; es probable que Debian no lo admita. Es probable que cause problemas como este.

El mismo problema en Fedora también.

Quizás debería haber un canal "beta", o algún mecanismo similar para que las personas realicen más pruebas antes del lanzamiento, en lugar de simplemente descargar una versión rota en pypi y hacer que las compilaciones de todos exploten.

@ fake-name Se hicieron dos prelanzamientos:

• 10.0.0b1 fue lanzado el 31 de marzo
• 10.0.0b2 fue lanzado el 2 de abril

@ fake-name además, la sugerencia general para el uso en todas las distribuciones es: use un virtualenv, no destroce el sistema, y ​​eso funciona: la gente simplemente lo sigue y luego se pregunta cuándo se rompe y culpa a pip

ha habido muchas pruebas manuales y automatizadas con virtualenvs que funciona

también en un virtualenv, al menos no debería haber un comando pip3 hecho por Debian, entonces, ¿de qué diablos estás hablando con esta ruptura en virtualenvs? Por favor, proporcione suficientes datos para verificar realmente en lugar de quejarse de las roturas sin proporcionar los datos necesarios para verificarlas.

pip está impulsada por voluntarios, no una empresa con docenas de empleados

~ Eliminado ~. estaba confundiendo esto con https://github.com/pypa/pip/issues/5220

Soy un derp.

Gracias, no me había dado cuenta de que reemplazar el pip del sistema era una mala idea, pero tiene sentido. Sin embargo, sería una buena experiencia de usuario si pip no se molestara por actualizar en ese caso. ¿Sería eso posible? Creo que mucha gente (incluyéndome a mí) simplemente haría cualquier cosa que "la cosa" les pida que hagan.

@ fake-name gracias por el seguimiento: es sorprendentemente común no coincidir con el problema de los detalles cuando un lanzamiento importante tiene un impacto multifacético y parte de él intenta arruinarte el día

Sería una buena experiencia de usuario si pip no se molestara por actualizar en ese caso

Los proveedores de distribución ciertamente podrían parchear pip para eliminar esa advertencia (o mejor, reemplazarla con una verificación similar contra los paquetes del sistema) junto con los otros parches que hacen. No estoy seguro de cómo base pip podría detectar que se está ejecutando desde una instalación empaquetada del sistema sin la cooperación de la distribución, pero si hay una manera de hacerlo, eso es algo que podríamos considerar (pero tenga en cuenta que, en mi experiencia, obtenemos como mucha retroalimentación negativa por equivocarse con tales heurísticas como lo hacemos nosotros por no incluir heurísticas en absoluto ...)

Prefiera siempre "python3 -m pip" sobre pip3 "o incluso mejor" / usr / bin / env python3 -m pip "es más seguro y permite evitar este problema con pip10

Resolvimos este problema limpiando hash en bash:

$ hash -d pip

O en guión (sh):

$ hash -r pip

También aborde este problema al crear imágenes de la ventana acoplable.

@RonnyPfannschmidt dice que "reemplazar el sistema pip usando pip es siempre un acto de vandalismo del sistema en el que el que lo inflige es responsable de las consecuencias", que tiene 6 pulgares arriba. Encuentro que este es un comentario especialmente obtuso dado que el pip me indicó que lo hiciera:

_Usted está usando pip versión 8.1.1, sin embargo la versión 10.0.0 está disponible.
Debería considerar la actualización a través del comando 'pip install --upgrade pip'.

Si hay algo de validez en ese comentario, entonces los creadores de pip deberían eliminar este mensaje y yo animaría a @RonnyPfannschmidt a plantear un problema en ese sentido y

@qacollective : creo que el argumento aquí es que las distribuciones han tomado pip, lo han modificado y lo han empaquetado nuevamente en sus repositorios. Como tal, no es realmente culpa de Pypi que el mensaje siga ahí.

La mayor parte de esto se debe a un montón de las distribuciones de tratar muy, muy difícil de volver a empaquetar todo en sus propios repositorios de paquetes. Sobre todo, las cosas se dejan pudrir.

Personalmente, al menos para python en ubuntu, desearía que lo dejaran. Básicamente, la versión de todos los paquetes de Python en apt varía desde muy, muy antiguo hasta fosilizado. Apt es básicamente inútil para Python, en mi humilde opinión.

FWIW, tiendo a encontrar que la mejor opción es nunca instalar el pip de distribución en primer lugar, sino instalarlo manualmente a través de get-pip.py . De esa manera, no tendrá problemas con que el administrador de paquetes de la plataforma conozca solo algunos de los paquetes de Python.

Utilice siempre --user para evitar matar su sistema

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

Debería manejar la mayoría de los casos de errores y resultar en la instalación de la versión correcta de pip en ˜/.local/bin .

Puedo confirmar que la solución de @standag está funcionando.

Un poco de trasfondo: después de la actualización (pip install -U pip) en un vanilla ubuntu 16.04 (AWS AMI) se llega a la siguiente situación:
$ RUTA = ..: / usr / local / bin: ... : / usr / bin: ...
/ usr / bin / pip sigue siendo la versión antigua / 'oem' (rota)
/ usr / local / bin / pip es el nuevo script v10 (funciona bien cuando se invoca directamente)

A pesar de que la versión de pip adecuada precede a la rota en el PATH, bash todavía recuerda la anterior, por lo que cuando la invocas como 'pip', la antigua y rota se ejecutará. hash-d pip o hash -r resuelve el problema.

Primero, algunas notas sobre lo que sucedió aquí en Debian / Ubuntu (y probablemente algunas distribuciones de Linux más):

• pip no admite el uso de sus componentes internos importándolo. Más sobre eso en la documentación aquí .
• Debian (por lo tanto, Ubuntu) no admite la modificación de los archivos administrados por el administrador de paquetes usando algo que, bueno, no es su administrador de paquetes.

Este problema se debe, bueno, a que ambos se violan de alguna manera.

• Debian usa los métodos internos de pip (que ya no funcionan debido a una reorganización de los componentes internos de pip). Debian está asumiendo aquí que la versión pip en sus repositorios es la que se instalaría.
• Ejecutar pip install --upgrade pip , como root, sin ningún otro parámetro, modifica los archivos que supuestamente debe administrar apt, lo que rompe el script de Debian.

Algunos consejos generales sobre Linux:

• Es un buen hábito usar --user siempre que esté fuera de un venv.

  pip install --upgrade --user pip
  

• Nunca ejecute pip con sudo a menos que sepa lo que está haciendo.

¿Cuál es la solución?

La solución de @standag es útil cuando esto es causado por el almacenamiento en caché de ejecutables de bash.

hash -r pip # or hash -d pip

Si ha modificado la instalación de pip de su administrador de paquetes del sistema operativo (por ejemplo, usando sudo pip ) y python -m pip todavía está funcionando, una solución es desinstalar la versión instalada de pip y reinstalar la versión instalada del administrador de paquetes .

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

Si no está en Debian / Ubuntu _y_ pip se rompió por usted, intente ejecutar:

python -m pip install --force-reinstall pip

Si lo anterior no resuelve sus problemas, presente un nuevo problema.

[editado por @pradyunsg : hacerlo más relevante para vincular a todas las personas con problemas similares a este comentario; actualice la sugerencia para incluir la desinstalación / reinstalación de la solución alternativa]

¿Qué hay de resolverlo fuera de la ventana acoplable? Está roto en mi sistema habitual y el comando hash no reconoció pip.
thinkdigital@thinkdigital-HP-Spectre-x360-Convertible:~$ hash -d pip bash: hash: pip: not found

Encontré pip3, versión 9.0.1 instalada en un virtualenv de un proyecto y lo copié en mi / usr / bin y funciona de nuevo. Aquí está el contenido del ejecutable pip3 para aquellos que también deseen arreglarlo ellos mismos.

# -*- 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())

Estoy seguro de que todo lo que tiene que hacer es guardarlo en un archivo llamado pip3, hacerlo ejecutable ejecutando sudo chmod + x ./pip3, ejecutar sudo apt remove python3-pip, y luego copiarlo al directorio bin ejecutando sudo cp ./pip3 / usr / bin.
Aquí está el archivo sin procesar para aquellos que solo quieren descargarlo y moverlo.
pip3.zip

Esto funciona para mi:
curl https://bootstrap.pypa.io/get-pip.py | sudo python

Lo siento, pero me gustaría señalar que ejecutar código Python curvado desde algún sitio web con acceso de root es terriblemente inseguro.

De acuerdo, y debo señalar que esta no es una recomendación oficial de pip. Como se ha dicho varias veces, debe usar el administrador de paquetes del sistema para actualizar o administrar la instalación de pip de su sistema, no get-pip, o incluso pip a través de sudo.

En este caso, la versión del administrador de paquetes del sistema no funciona. Incluso
después de purgar y reinstalar.

El jueves 19 de abril de 2018 a la 1:53 a.m. Paul Moore [email protected] escribió:

De acuerdo, y debo señalar que esto no es un pip oficial
recomendación. Como se ha dicho varias veces, debería utilizar
el administrador de paquetes de su sistema para actualizar o administrar el pip de su sistema
instalación, no get-pip, o incluso pip a través de sudo.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pip/issues/5221#issuecomment-382660881 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AV-Hfecz8l1NEyq3vsih0DpNP7QYdxuvks5tqFCdgaJpZM4TVEq6
.

Si reinstalar el paquete del sistema aún no funciona, verifique si tiene pip10 en algún lugar de / usr / local / y elimine toda la carpeta.

Reemplazar el de / usr / bin funcionó para mí aunque CREO que es
el que estaba instalando el administrador de paquetes del sistema.

[ @pradyunsg contenido de correo electrónico

@ThinkDigitalRepair ¿Lo siguiente ayuda?

En otros casos, querrá pasar --user al instalar / actualizar paquetes. TBH, en Linux, es un buen hábito usar --user .

pip install --upgrade --user pip

Está bien. Gracias. Lo arruiné siguiendo un tutorial de Jupyter Notebook de su
sitio que le dice que actualice pip directamente. Copiar y pegar sin
conocer las consecuencias golpea de nuevo. :(

[ @pradyunsg contenido de correo electrónico

Es de esperar que

Cerrando este problema ahora ya que no hay nada procesable aquí desde el final de pip.

Cualquiera que busque cómo solucionar / solucionar este problema, consulte https://github.com/pypa/pip/issues/5221#issuecomment -382069604.

@pradyunsg en muchos casos, las soluciones dadas en ese comentario no funcionarán. Bajo un Ubuntu 17.10 nuevo, ejecute pip install --upgrade pip : después de eso, el comando pip se romperá y las soluciones del comentario no lo solucionarán. ¡Y no deberían!

Tener un sistema instalado pip 9 con un usuario instalado pip 10, hace que el script pip del sistema intente importar main () desde el usuario pip 10, con una ruta de importación incorrecta. Hash -r o -d no solucionará eso porque el comando pip seguirá ejecutando el sistema pip de forma predeterminada. Y tampoco lo solucionará actualizando el pip del usuario, ya que el pip del sistema seguirá siendo 9, el pip del usuario seguirá siendo 10, por lo que la importación seguirá fallando.

La solución para esos casos debe ser desinstalar uno de ambos pips.

• python -m pip uninstall pip --user , manteniendo el pip del sistema, que es más antiguo

o

• sudo apt remove python-pip y mantenga el pip instalado por el usuario, al que no se podrá acceder ejecutando pip en la terminal de forma predeterminada. Deberá ejecutarlo con python -m pip , o agregar las rutas a su PATH env var, etc.

Todo esto se aplica a ambos, pip bajo python 2 y 3.

En todos mis sistemas Ubuntu (16.04, 17.10. 18.04), tengo el pip del sistema a la versión anterior y el usuario está con pip 10 y nunca veo su error de importación.
¿Estás seguro de que no tienes el pip de un sistema dañado?

@gsemet probablemente agregó ~/.local/bin a su PATH env var (o tal vez usando un shell diferente y más inteligente que el bash predeterminado), por lo que cuando ejecuta pip usa el script pip 10 instalado por el usuario, y no el script pip 9 instalado por el sistema. En Ubuntu esto no es así por defecto. Se puede hacer, seguro, y desearía que viniera así por defecto. Pero de forma predeterminada, el comando pip llamará al pip instalado en el sistema, incluso si tiene un usuario instalado.

Cómo reproducir esto con una instalación nueva de Ubuntu 17.10, incluida la evidencia de que los comandos en el comentario 5221 no logran solucionarlo, y lo que propuse lo soluciona.

Instalación de ambos pips (sistema y usuario), que rompe el comando pip:

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

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

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

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

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

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

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

Como puede ver, el comando pip apunta al pip del sistema por defecto, no al usuario instalado.

Comandos del comentario referenciado, evidencia de que no solucionan el problema:

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

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

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

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

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

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

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

Como puede ver, siempre que ambos pips estén instalados y el comando pip apunte al pip del sistema (comportamiento predeterminado en Ubuntu), el problema persistirá.

Opción de reparación 1:

Elimine el pip del sistema, mantenga el pip del usuario, que de forma predeterminada no es accesible a través del comando pip (por lo que debe usar python -m pip ).

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

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

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

Puede agregar ~/.local/bin a su var PATH env, para poder usar el comando pip con el usuario pip.

Opción de reparación 2:

Elimine el pip del usuario, mantenga el pip del sistema, que es más antiguo pero de forma predeterminada tiene un comando pip en funcionamiento en la ruta.

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 Seguro, eso es necesario para admitir el paquete 'pip install --user' instalable por el usuario. Pero creo que debería decirse a los usuarios "si desea forzar la actualización a pip 10 antes de que se actualice el paquete debian / ubuntu, debe usar pip install --user --upgrade pip y asegurarse de que $HOME/.local/bin esté en su camino .Es simple de hacer.

@gsemet Estoy de acuerdo, se debe informar a los usuarios sobre el requisito de ruta. Esto no se menciona en el comentario al que se hace referencia desde otros hilos como la solución, y en un caso la discusión se bloqueó incluso después de que un usuario dijo que ejecutó esos comandos y no resolvió el problema: /

@fisadev Muchas gracias. Fix option1 realmente ayuda.

@RonnyPfannschmidt

Reemplazar el sistema pip usando pip es siempre un acto de vandalismo del sistema donde el que lo inflige es responsable de las consecuencias.

es un comentario de vandalismo mental. Como si la persona que realiza la actualización (ingenua) se dispusiera intencionalmente a dañar su propia instalación ... Si ese fuera el caso, entonces pip no debería estar molestando al usuario para que actualice de 9.0.1 a 10.0.1 con cada comando de un solo pip ejecutado. Yo mismo seguí esa recomendación y terminé en este lío.

Por suerte:
sudo python -m pip install pip==9.0.1
era un remedio bastante fácil.

Sin embargo, culpar a la víctima no es una respuesta.

¡Hola @ rod-app!

Si ese fuera el caso, entonces pip no debería estar molestando al usuario para que actualice de 9.0.1 a 10.0.1 con cada comando de pip ejecutado.

Hemos notado esto y hemos trabajado con los proveedores de sistemas operativos para evitarlo en futuras versiones de pip. - # 5346.

Para abordar el problema, corrí ...

sudo geany -i /usr/bin/pip

... y edité el / usr / bin / pip proporcionado por Debian para reemplazarlo con ...

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

y el equivalente para / usr / bin / pip3 (tenga en cuenta que esto invoca python3 en su lugar).

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

... que recupera la funcionalidad completa de pip a pesar de la versión 10 instalada en los paquetes de mi sitio. Supongo que esto durará exactamente el tiempo que debian tarde en arreglarlo (o volver a romperlo) enviando un paquete python-pip actualizado. Por qué no usaron el paquete main en primer lugar, no lo sé.

Versión oficial

La versión de pip instalada en .local/bin/pip muestra a continuación es un poco más elegante e incluye algunas sustituciones para eliminar las extensiones -script, .py, .pyw y .exe de los argumentos pasados, pero no sé qué hace eso o por qué lo necesito, así que lo dejé como se indica arriba para simplificar.

#!/usr/bin/python

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

from pip._internal import main

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

Encontré una causa no relacionada con este problema de pip v10. Al actualizar pip usando un pip de sistema muy antiguo (v1.5.6 en Debian Jessie, es decir, oldstable) para el cual --system es el predeterminado, noté que se instalaron scripts incorrectos , por ejemplo, /usr/local/bin/pip contienen from pip import main - que encontré mirando los archivos. Supongo que esto se debe a que el pip más antiguo (o quizás los paquetes de instalación que usa) instalan el archivo .whl incorrectamente.

python -m pip install --force-reinstall pip arregló esto.

5599 proporciona información y proporciona una única ubicación para buscar ayuda para resolver este problema para los usuarios finales.

La sección de comentarios de ese problema está abierta para que los usuarios discutan problemas y soluciones específicos. :)