Aquí está la salida 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

Supongo que esto es probablemente una consecuencia de Pipenv dependiendo de pip, pero no estoy seguro si Pipenv debería ser responsable de esto. Quizás Debian debería hacerlo porque fueron ellos quienes rompieron el acoplamiento Python-pip. Ciertamente, Pipenv tampoco es el único paquete que depende de pip, pero no estoy seguro de cuál es la mejor práctica aquí.

@ncoghlan, ¿ podría

1. ¿Un paquete debe depender de pip?
2. Si 1. es sí, ¿debería ser responsable de este tipo de conflicto con el administrador de paquetes del sistema?
3. Si 2. es sí, ¿cómo?
4. Si 2. es no, ¿quién debería ser responsable? ¿Debería indicarse al usuario que utilice una solución alternativa en su lugar?

En cualquier caso, probablemente nunca deberías sudo pip install nada en Ubuntu de todos modos. Deberías hacer una de las siguientes cosas en su lugar

• Use APT hasta el final
• pip install --user
• Un administrador personalizado como pipsi

O mejor aún, evite el sistema Python por completo y use pyenv u otros administradores de tiempo de ejecución de Python en su lugar.

Rasca esos. Evite Python de APT, punto.

Probablemente nunca debería sudo pip instalar nada en Ubuntu de todos modos

De hecho, nunca lo hice. Soy consciente de los problemas de usar sudo pip en Ubuntu, así que uso apt siempre que sea posible o me quedo con --user .

Ah, veo el problema ahora. Los módulos de usuario tienen prioridad sobre los del sistema, pero /usr/bin está antes de $HOME/.local/bin en usted PATH . /usr/bin/python intenta importar la instalación del pip del sistema (que todavía es 9.x), pero terminó encontrando la instalación del usuario (que es 10.x). Que desastre.

2095 es lo mismo, pero quiero mantener esto abierto porque creo que debería haber una solución más sólida que depender de que el usuario tenga un PATH amigable.

es bastante estable cuando el usuario tiene:

• ˜/.local/bin al principio del PATH del usuario. Debería ser el predeterminado en Ubuntu, desde 16.10 . Es una buena práctica tenerlo, ya que permite pip install --user comportamiento de
• el usuario siempre debe usar pip install --user . Jugar con el pip del sistema es realmente malo en todas las distribuciones, incluso las extrañas carpetas "dist-packages / site-packages" en Debian no protegen contra los errores del usuario.

Hemos asegurado este comportamiento en todas nuestras instalaciones de usuarios de ubuntu (organización de más de 1000 instalaciones de varias versiones de ubuntu), y la transición a pip10 funcionó a la perfección.

Si bien estoy de acuerdo en que Python y su ecosistema son complicados y que sería mejor si las personas no tuvieran que configurar correctamente sus rutas para obtener el orden de búsqueda correcto, desafortunadamente, esto es solo un hecho sobre la forma en que funciona la instalación en este momento en los administradores de paquetes. y no es exactamente un problema de pipenv per se. No creo que podamos hacer mucho para abordarlo de forma independiente, es más un problema que debe abordarse en las listas de correo de Python

Ah, ahora veo cuál es el problema, gracias. Nunca pensé que la ruta pudiera influir en esto, por eso no se me ocurrió incluirlo en la descripción del problema. Lo siento y gracias por tu ayuda.

Lo que me arregló fue agregar

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

al perfil.

Editar: asegúrese de ejecutar hash -r o ingrese un nuevo shell para que este cambio surta efecto.

No creo que podamos hacer mucho para abordarlo de forma independiente

¿Quizás podría haber algunas instrucciones de instalación más detalladas o advertencias? No tengo mucha experiencia con el funcionamiento de pip, pero es posible que haya leído una nota sobre problemas de ruta. Pero supongo que el ecosistema de diferentes administradores de paquetes y distribuciones es demasiado complejo para una simple regla ...

@slhck es realmente tan frustrante que haya este xkcd específicamente sobre entornos de Python y sudo y las instalaciones del administrador de paquetes hace unos días

Aquí hay una buena guía paso a paso que utilicé con éxito en Ubuntu 18.04:
https://phoikoi.io/2018/04/03/bootstrap-pipenv-debian.html

También está https://github.com/pypa/python-packaging-user-guide/issues/396 , que analiza la cuestión de si podemos o no crear la lista de verificación o el script de resolución de problemas para ayudar a la gente a identificar y resolver problemas potenciales en su entorno. Tomaré nota allí sobre el potencial de PATH / sys.path conflictos de pedidos.

Gracias, @slhck . Su solución alternativa de exportación me ahorró la mayor parte de tiempo; Lo agregué a / etc / profile.

Es realmente tonto que tengamos 2 niveles de paquetes de software en Linux. Peor aún, con la última versión de * buntus, ambos sabores de uno de ellos (pip / pip3) se rompen.

Lo escribí en Launchpad: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1772746

@texadactyl Debian tiene esta política (olvido cuál es) de que pip no debería instalarse de forma predeterminada, y se han apegado a ella con muchas quejas anteriores. La tradición está profundamente arraigada en Debian. Me encantaría que lo reconsideraran, pero dudo mucho que lo hagan.

Estaba enfrentando el mismo problema en Ubuntu 18 y Python 3.6

A continuación se muestran los pasos que seguí:

1) En primer lugar, recibí el error:

Rastreo (llamadas recientes más última):
Archivo "/ usr / bin / pip", línea 9, en
desde pip import main
ImportError: no se puede importar el nombre principal

2) Modifiqué el archivo / user / bin / pip a:

importar sys
desde pip._internal import main como _main
if __name__ == '__main__':
sys.exit (main ())

3) Entonces, comenzó a darme este error:

Rastreo (llamadas recientes más última):
Archivo "/ usr / bin / pip3", línea 11, en
sys.exit (main ())
NameError: el nombre 'principal' no está definido

4) Modifiqué / usr / bin / pip3 a:

importar sys
desde pip._internal import main como _main
if __name__ == '__main__':
sys.exit (_main ())

5) Entonces comencé a recibir el error:

Rastreo (llamadas recientes más última):
Archivo "/ usr / bin / pip3", línea 11, en
sys.exit (main ())
NameError: el nombre 'principal' no está definido

6) Cambié el nombre de main () a _main (), y listo ... ¡¡¡funcionó !!! :) :)

Si bien eso puede haber resuelto el problema, este es un mal consejo. No debe modificar manualmente los archivos del sistema. Por favor, eche un vistazo a mi comentario anterior para encontrar una solución.

editar: La solución de @slhck lo resolvió. Necesita tener ~/.local/bin en su camino

Obteniendo el mismo problema en 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

Solo quiero agregar que también me topé con este problema. Ya tenía ~ / .local / bin como lo primero en mi camino. El problema es cómo bash procesa los comandos. La solución a este problema se encontró aquí: https://github.com/pypa/pip/issues/5221#issuecomment -381568428

@thernstig Sí, es correcto: agregué el comando hash -r a mi solución anterior, que olvidé mencionar explícitamente.

@slhck No hay problema, me alegro de poder ayudar

Me di cuenta de que el problema está cerrado, pero estoy publicando con la esperanza de que esto pueda ayudar a evitar modificaciones en PATH. Me encontré con esto hoy cuando configuré una nueva máquina Ubuntu 18.04 y pude resolverlo sin modificaciones de PATH, aunque reinicié (estoy bastante seguro de que la sesión / inicio de sesión funcionará, pero no verifiqué).

Después de instalar pip3 a través de python3-pip y pipenv con pip3 install --user pipenv , recibí el error de asunto. Estaba a punto de usar la solución alternativa de @slhck cuando noté lo siguiente en ~/.profile (stock, no tengo modificaciones):

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

Curioso, reinicié y, efectivamente, el problema se resolvió ya que mi .local/bin ahora estaba al comienzo de mi PATH y pip3 funcionó nuevamente.

@jlitzingerdev Estoy bastante seguro de que la ruta es la predeterminada, es solo que para mi sistema, ya que estaba usando un shell y un perfil diferentes, lo eliminé o lo construí desde cero, de ahí mi "solución" que no debería haber sido necesaria en primer lugar. Me alegra que lo hayas resuelto.

@slhck Lo es, pero puede que no esté en PATH en el primer inicio de sesión porque es posible que ~/.local/bin no exista, o tal fue mi caso específico.

¿Qué tenemos que hacer?

Solo quiero agradecerle por incluir comandos de restauración, estaba teniendo problemas para que pip volviera a funcionar.

Quiero instalar pipenv en Ubuntu 18.04. Cuando lo hago, se rompe pip / pip3.

Resultado Esperado

Versión instalada y funcional de pipenv.

Resultado actual

pip / pip3 están rotos, dependiendo de si quería instalar pipenv a través de pip o pip3.

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

Pasos para replicar

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.

Para solucionar el problema, tengo que ejecutar:

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

Pero no puedo instalar pipenv usando pip. La instalación a través de apt no funciona porque no hay PPA disponible.

tengo 3 pip en mi ubuntu 18 pip, pip3 y pip3.6 pip es para 2.7 pip3 es para 3.5 y pip3.6 para 3.6 ahora que pip muestra la ubicación del archivo en .local / bin. Eliminé el archivo pip y pip3 de aquí. ahora que pip3 me muestra el / usr / bin / pip3. ejecute el comando sudo nano / usr / bin / pip3 cambie la primera línea para el intérprete como! # / usr / bin / python3 a # / usr / bin / python3.5. funciona para mi. todas mis pepitas funcionan. espero que esto ayude

tengo 3 pip en mi ubuntu 18 pip, pip3 y pip3.6 pip es para 2.7 pip3 es para 3.5 y pip3.6 para 3.6 ahora que pip muestra la ubicación del archivo en .local / bin. Eliminé el archivo pip y pip3 de aquí. ahora que pip3 me muestra el / usr / bin / pip3. ejecute el comando sudo nano / usr / bin / pip3 cambie la primera línea para el intérprete como! # / usr / bin / python3 a # / usr / bin / python3.5. funciona para mi. todas mis pepitas funcionan. espero que esto ayude

Realmente no se recomiendan todos estos pasos. No debe editar manualmente archivos en /usr/bin . En su lugar, intente desinstalar pip como se mencionó anteriormente y vuelva a instalar a través de apt . Esto debería proporcionarle las instalaciones correctas del sistema. Si luego tiene problemas con pipenv , abra un nuevo problema y describa su problema en lugar de intentar soluciones alternativas.

reinstalar a través de apt como se mencionó anteriormente no cambiará nada, ya que genera la misma salida. Los estados simples no pueden importar el nombre principal y al hacer la importación de pip en un intérprete de Python, lo importa como módulo, lo que significa que el nombre principal no está disponible en el módulo donde está tratando de buscar. Ahora no sugerí la edición anterior a ciegas. Como entusiasta del software, cuando estaba en ubuntu14, verifiqué el archivo pip y tiene el mismo código que el de ubuntu18 pip3. Entonces, ¿qué cambió? La versión de Python que viene empaquetada con él lo hizo.

Porque pip para python3.5 y 2.7 solo tiene main definido en el módulo pip.
Y python3.6 lo tiene definido en pip._internal

Ahora las dos declaraciones anteriores resuelven el problema de todos.

el problema radica en que el intérprete se utilizó a sí mismo

python3; pero a qué pitón se refiere
Los desarrolladores que solo tenían python 2.7 y cambiaron a ubuntu18 probablemente tendrán python 3 como python3.6

pero ¿qué pasa con aquellos que tenían python3.4 pr 3.5 instalado? Primero, python3 hizo referencia a python3.5 y ahora, después de la actualización, se referirá a ppython3.6

Entonces, la forma en que debian lo manejó lo rompió

simplemente indicando el intérprete correcto resolverá el problema
de ambos teniendo errores

desde pip import main
y
desde pip._internal import main como _main

Gracias
PD
En este punto debo decir que dar una conferencia sobre lo que no está bien en otra plataforma, pero en github, donde otros desarrolladores apasionados vienen a resolver sus molestias; especialmente cuando intentan ejecutar una gran cantidad de comandos o editar algunos archivos de configuración para que funcione, debo decir que no sea tan inteligente que comience a desanimar a la gente de esta manera.

NOTA: Las nuevas versiones no funcionarán si no cambian el código. Agregarán soluciones para que funcione para todos los que lo desinstalen e instalen

Espero que en este punto lo consigas. Paz y no me vuelvas a molestar

@ r-tron18 Lamento que se sienta sermoneado por lo que se pretendía como una sugerencia constructiva: no tener que modificar un archivo del sistema. Por el poco contexto que estaba dando en su publicación original, era imposible saber si es un usuario experimentado que sabe lo que está haciendo, o simplemente está aplicando soluciones alternativas que podrían haber encontrado en otro lugar. Paso mucho tiempo en varios sitios web de solución de problemas y preguntas y respuestas, y supongo que estarías de acuerdo en que no deberíamos alentar a los usuarios a probar arreglos aleatorios o sudo -editar un archivo enviado por el sistema, que a menudo conduce a más errores y confusión. Ese es un problema más general.

Todavía no estoy convencido de que lo que sugieres sea una solución confiable. Y: podemos tener una discusión civil sobre los méritos de esa solución: GitHub es un lugar donde puedo expresar eso.

La razón es: cambiar el shebang de /usr/bin/pip3 a #!/usr/bin/python3.5 solo te dejará atascado con esa versión. Debería leer #!/usr/bin/python3 , y debería ser un enlace simbólico a /usr/bin/python3.6 (o lo que sea que esté actualizado en su sistema). Cualquier actualización de Python probablemente cambiará ese archivo de todos modos.

Tu dices:

pero ¿qué pasa con aquellos que tenían python3.4 pr 3.5 instalado? Primero, python3 hizo referencia a python3.5 y ahora, después de la actualización, se referirá a ppython3.6
Entonces, la forma en que debian lo manejó lo rompió

¿Está diciendo que después de una actualización de Python 3.5 a Python 3.6, ese enlace simbólico python3 no se actualizó? Si lo que está observando es de hecho un error con Debian o Ubuntu, donde una actualización de Python no pudo establecer enlaces simbólicos correctos, entonces ese error probablemente debería abordarse en sentido ascendente, ¿no?

Me di cuenta de que el problema está cerrado, pero estoy publicando con la esperanza de que esto pueda ayudar a evitar modificaciones en PATH. Me encontré con esto hoy cuando configuré una nueva máquina Ubuntu 18.04 y pude resolverlo sin modificaciones de PATH, aunque reinicié (estoy bastante seguro de que la sesión / inicio de sesión funcionará, pero no verifiqué).

Después de instalar pip3 a través de python3-pip y pipenv con pip3 install --user pipenv , recibí el error de asunto. Estaba a punto de usar la solución alternativa de @slhck cuando noté lo siguiente en ~/.profile (stock, no tengo modificaciones):

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

Curioso, reinicié y, efectivamente, el problema se resolvió ya que mi .local/bin ahora estaba al comienzo de mi PATH y pip3 funcionó nuevamente.

Funciona para mí, después de reiniciar, todo funciona bien. (después de la instalación: "pip3 install --user pipenv" reinicie su sistema y funcionará.