Вот результат работы 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

Я предполагаю, что это, вероятно, следствие зависимости Pipenv от pip, но я не уверен, что Pipenv должен нести за это ответственность. Может быть, Debian должен это сделать, потому что именно они нарушили связь Python-pip. Pipenv, безусловно, не единственный пакет, зависящий от pip, но я не уверен, что здесь лучше всего.

@ncoghlan не могли бы вы немного рассказать об этой теме? Конкретно

1. Должен ли пакет зависеть от пункта?
2. Если 1. - да, должен ли он быть ответственным за такого рода конфликты с системным менеджером пакетов?
3. Если 2. да, то как?
4. Если 2. нет, кто должен нести ответственность? Следует ли дать пользователю указание использовать вместо этого обходной путь?

В любом случае вам, вероятно, никогда не следует ничего sudo pip install на Ubuntu. Вместо этого вы должны сделать одно из следующих

• Используйте APT до конца
• pip install --user
• Пользовательский менеджер, такой как pipsi

Или, что еще лучше, вообще избегайте системного Python и вместо этого используйте pyenv или другие диспетчеры времени выполнения Python.

Поцарапайте их. Избегайте Python из APT, и точка.

вы, вероятно, никогда не должны sudo pip устанавливать что-либо на Ubuntu

На самом деле я никогда этого не делал. Я знаю о проблемах использования sudo pip в Ubuntu, поэтому я использую apt когда это возможно, или придерживаюсь --user .

Ах, теперь я вижу проблему. Пользовательские модули имеют приоритет над системными, но /usr/bin перед $HOME/.local/bin в вашем PATH . /usr/bin/python пытается импортировать установку системного пипа (которая по-прежнему 9.x), но в итоге обнаруживает установку пользователя (это 10.x). Какой беспорядок.

2095 то же самое, но я хочу оставить это открытым, потому что я думаю, что должно быть более надежное решение, чем зависеть от дружелюбного пользователя PATH .

он довольно стабилен, когда у пользователя есть:

• ˜/.local/bin в начале PATH . Должно быть по умолчанию в Ubuntu, начиная с 16.10 . Это хорошая практика, поскольку она обеспечивает поведение pip install --user которое является совершенно допустимым вариантом использования.
• пользователь всегда должен использовать pip install --user . Возиться с системным пипом действительно плохо в каждом дистрибутиве, даже странные папки «dist-packages / site-packages» в debian не защищают от ошибок со стороны пользователя.

Мы обеспечили такое поведение во всех наших пользовательских установках ubuntu (организация более 1000 установок различных версий ubuntu), и переход на pip10 сработал как шарм.

Хотя я согласен с тем, что python и его экосистема сложны и было бы лучше, если бы людям не приходилось должным образом настраивать свои пути, чтобы получить правильный порядок поиска, к сожалению, это просто факт о том, как сейчас работает установка в диспетчерах пакетов. и это не совсем проблема pipenv как таковая. Я не думаю, что мы можем многое сделать, чтобы самостоятельно решить эту проблему, это скорее проблема, которую нужно решить в списках рассылки python.

Ах, теперь я понимаю, в чем проблема, спасибо. Никогда не думал, что путь может повлиять на это, поэтому мне не пришло в голову включить его в описание проблемы. Извините за это и спасибо за вашу помощь.

Что исправило для меня, так это добавление

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

в профиль.

Изменить: убедитесь, что вы запустили hash -r или вошли в новую оболочку, чтобы это изменение вступило в силу.

Я не думаю, что мы можем многое сделать, чтобы решить эту проблему самостоятельно.

Может быть, есть более подробные инструкции по установке или предостережения? Я не слишком разбираюсь в том, как работает pip, но, возможно, я читал заметку о проблемах с путями. Но я полагаю, что экосистема различных менеджеров пакетов и дистрибутивов слишком сложна для простого правила ...

@slhck на самом деле так расстраивает, что несколько дней назад был этот xkcd, посвященный средам python и установкам sudo и диспетчера пакетов

Вот хорошее пошаговое руководство, которое я успешно использовал в Ubuntu 18.04:
https://phoikoi.io/2018/04/03/bootstrap-pipenv-debian.html

Там также https://github.com/pypa/python-packaging-user-guide/issues/396 , где обсуждается вопрос о том, сможем ли мы разработать контрольный список или сценарий устранения неполадок, чтобы помочь людям идентифицировать и решать потенциальные проблемы в их среде. Я сделаю заметку о возможных конфликтах порядка PATH / sys.path .

Спасибо, @slhck . Ваш обходной путь экспорта сэкономил мне больше всего времени; Я добавил его в / etc / profile.

Действительно глупо, что у нас в Linux есть 2 уровня упаковки программного обеспечения. Хуже того, с последней версией * buntus обе разновидности одного из них (pip / pip3) не работают.

Я написал это на Launchpad: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1772746

@texadactyl В Debian есть такая политика (я забыл, что это такое), согласно которой pip не должен устанавливаться по умолчанию, и они придерживались этой политики с множеством предыдущих жалоб. Эта традиция уходит глубоко в корни Debian. Я был бы рад, если бы они смогли переосмыслить это, но я очень сомневаюсь, что они так и поступили бы.

Я столкнулся с той же проблемой в Ubuntu 18 и Python 3.6.

Ниже приведены шаги, которые я выполнил:

1) Сначала я получал сообщение об ошибке:

Отслеживание (последний вызов последний):
Файл "/ usr / bin / pip", строка 9, в
из основного пункта импорта
ImportError: невозможно импортировать имя main

2) Я изменил файл / user / bin / pip на:

import sys
из pip._internal import main как _main
если __name__ == '__main__':
sys.exit (главная ())

3) Затем он начал выдавать мне эту ошибку:

Отслеживание (последний вызов последний):
Файл "/ usr / bin / pip3", строка 11, в
sys.exit (главная ())
NameError: имя main не определено

4) Я изменил / usr / bin / pip3 на:

import sys
из pip._internal import main как _main
если __name__ == '__main__':
sys.exit (_main ())

5) Затем я начал получать ошибку:

Отслеживание (последний вызов последний):
Файл "/ usr / bin / pip3", строка 11, в
sys.exit (главная ())
NameError: имя main не определено

6) Я переименовал main () в _main (), и вуаля .. это сработало !!! :) :)

Хотя это могло решить проблему для вас, это довольно плохой совет. Вы не должны вручную изменять системные файлы. Пожалуйста, ознакомьтесь с моим предыдущим комментарием, чтобы найти решение.

Редактирование: @slhck «s решение решило. На вашем пути должно быть ~/.local/bin

Та же проблема возникает на 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

Я просто хочу добавить, что я тоже наткнулся на эту проблему. У меня уже был ~ / .local / bin в качестве первого шага на моем пути. Проблема в том, как bash хеширует команды. Решение этой проблемы было найдено здесь: https://github.com/pypa/pip/issues/5221#issuecomment -381568428

@thernstig Да, это правильно - я добавил в свое решение необходимую команду hash -r , о которой забыл явно упомянуть.

@slhck Без проблем, рад, что смог помочь

Я понял, что проблема закрыта, но отправляю сообщение с надеждой, что это поможет избежать изменений в PATH. Я столкнулся с этим сегодня при настройке новой машины Ubuntu 18.04 и смог решить эту проблему без изменений PATH, хотя я перезагрузился (я уверен, что выход / вход будет работать, но не проверял).

После установки pip3 через python3-pip и pipenv через pip3 install --user pipenv я получил сообщение об ошибке. Я собирался использовать обходной путь от @slhck, когда заметил следующее в ~/.profile (на складе, у меня нет модификаций):

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

Любопытно, я перезагрузился и, конечно же, проблема была решена, поскольку мой .local/bin был теперь в начале моего PATH, и pip3 снова работал.

@jlitzingerdev Я почти уверен, что путь

@slhck Это так, но его может не быть в PATH при первом входе в систему, потому что ~/.local/bin может не существовать, или это был мой конкретный случай.

Что мы должны сделать?

Просто хочу поблагодарить вас за включение команд восстановления, мне не удалось заставить pip снова работать.

Я хочу установить pipenv под Ubuntu 18.04. Когда я так делаю, ломается pip / pip3.

Ожидаемый результат

Установленная и рабочая версия pipenv.

Фактический результат

pip / pip3 не работают, в зависимости от того, хотел ли я установить pipenv через pip или pip3.

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

Шаги по воспроизведению

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.

Чтобы решить проблему, мне нужно запустить:

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

Но я не могу установить pipenv с помощью pip. Установка через apt не работает, потому что PPA недоступен ..

У меня есть 3 пункта в моем ubuntu 18 pip, pip3 и pip3.6 pip для 2.7 pip3 для 3.5 и pip3.6 для 3.6, который теперь показывает местоположение файла в .local / bin. Я удалил отсюда файл pip и pip3. теперь какой pip3 показывает мне / usr / bin / pip3. запустите команду sudo nano / usr / bin / pip3 измените первую строку для интерпретатора как! # / usr / bin / python3 на # / usr / bin / python3.5. работает для меня. все мои пипсы работают. надеюсь, это поможет

У меня есть 3 пункта в моем ubuntu 18 pip, pip3 и pip3.6 pip для 2.7 pip3 для 3.5 и pip3.6 для 3.6, который теперь показывает местоположение файла в .local / bin. Я удалил отсюда файл pip и pip3. теперь какой pip3 показывает мне / usr / bin / pip3. запустите команду sudo nano / usr / bin / pip3 измените первую строку для интерпретатора как! # / usr / bin / python3 на # / usr / bin / python3.5. работает для меня. все мои пипсы работают. надеюсь, это поможет

Все эти шаги действительно не приветствуются. Вы не должны вручную редактировать файлы в /usr/bin . Вместо этого попробуйте удалить pip, как указано выше, и переустановить через apt . Это должно обеспечить вам правильную установку системы. Если после этого у вас возникнут проблемы с pipenv , пожалуйста, откройте новую проблему и опишите свою проблему, а не пытайтесь обходные пути.

переустановка через apt, как упомянуто выше, ничего не изменит, поскольку генерирует тот же результат. Простые состояния не могут импортировать имя main, и при выполнении import pip в интерпретаторе python он импортирует его как модуль, что означает, что имя main недоступно в модуле, в котором он пытается искать. Теперь я не предлагал выше редактировать вслепую. Как энтузиаст программного обеспечения, когда я был на ubuntu14, я проверил файл pip, и он имеет тот же код, что и в ubuntu18 pip3. так что изменилось. Версия python, которая поставляется в комплекте с ним, сделала.

Поскольку pip для python3.5 и 2.7 имеет только main, определенный в модуле pip.
И python3.6 определил это в pip._internal

Теперь два приведенных выше утверждения решают все проблемы.

проблема заключается в используемом интерпретаторе

python3; но на какой питон он ссылается
Разработчики, у которых был только python 2.7 и перешли на ubuntu18, скорее всего, будут иметь python 3 как python3.6.

а как быть с теми, у кого установлен python3.4 pr 3.5. Сначала python3 ссылался на python3.5, а теперь после обновления он будет ссылаться на ppython3.6

Итак, то, как это было обработано debian, сломало его

просто указание правильного интерпретатора решит проблему
у обоих есть ошибки

из основного пункта импорта
а также
из pip._internal import main как _main

Спасибо
пс
Здесь я должен сказать, что чтение лекций о том, чего нельзя делать, будет нормально на другой платформе, но на github, куда другие увлеченные разработчики приходят, чтобы решить свои проблемы; особенно когда они пытаются запустить множество команд или отредактировать некоторые файлы конфигурации, я должен сказать, не будь настолько умным, чтобы начать отговаривать таких людей.

ПРИМЕЧАНИЕ. Новые версии не будут работать, если они не изменят код. Они добавят обходные пути, чтобы он работал для всех, удаляющих и устанавливающих его.

Я надеюсь, что на этом этапе вы это поймете. Мир и больше не беспокой меня

@ r-tron18 Мне жаль, что вы чувствуете, что вас насолили тем, что было задумано как конструктивное предложение - не изменять системный файл. Из небольшого контекста, который вы давали в своем исходном посте, было невозможно сказать, являетесь ли вы опытным пользователем, который знает, что делает, или просто применяете обходные пути, которые они могли найти в другом месте. Я трачу много времени на различные веб-сайты по устранению неполадок и вопросов и ответов, и я думаю, вы согласитесь с тем, что мы не должны поощрять пользователей пробовать случайные исправления или sudo -редактировать файл, поставляемый системой, что часто приводит к большему ошибки и путаница. Это скорее общий вопрос.

Я все еще не уверен, что то, что вы предлагаете, является надежным решением. И: у нас может быть гражданское обсуждение достоинств этого решения - GitHub - это место, где мне разрешено выразить это.

Причина в том, что изменение shebang /usr/bin/pip3 на #!/usr/bin/python3.5 только заставит вас застрять в этой версии. Он должен читать #!/usr/bin/python3 , и это должна быть символическая ссылка на /usr/bin/python3.6 (или что-то еще, что есть в вашей системе). Любое обновление Python, скорее всего, все равно изменит этот файл.

Ты говоришь:

а как быть с теми, у кого установлен python3.4 pr 3.5. Сначала python3 ссылался на python3.5, а теперь после обновления он будет ссылаться на ppython3.6
Итак, то, как это было обработано debian, сломало его

Вы хотите сказать, что после обновления Python 3.5 до Python 3.6 эта символическая ссылка python3 не была обновлена? Если то, что вы наблюдаете, действительно является ошибкой Debian или Ubuntu, когда при обновлении Python не удалось установить правильные символические ссылки, то эту ошибку, вероятно, следует устранить в восходящем направлении, не так ли?

Я понял, что проблема закрыта, но отправляю сообщение с надеждой, что это поможет избежать изменений в PATH. Я столкнулся с этим сегодня при настройке новой машины Ubuntu 18.04 и смог решить эту проблему без изменений PATH, хотя я перезагрузился (я уверен, что выход / вход будет работать, но не проверял).

После установки pip3 через python3-pip и pipenv через pip3 install --user pipenv я получил сообщение об ошибке. Я собирался использовать обходной путь от @slhck, когда заметил следующее в ~/.profile (на складе, у меня нет модификаций):

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

Любопытно, я перезагрузился и, конечно же, проблема была решена, поскольку мой .local/bin был теперь в начале моего PATH, и pip3 снова работал.

У меня работает, после перезагрузки все работает нормально. (после установки: "pip3 install --user pipenv" перезапустите вашу систему, и она будет работать.