это проблема Debian

к дополнительному примечанию - замена системного пипа с помощью пипса всегда является актом системного вандализма, когда тот, кто его вызывает, несет ответственность за последствия

Я предлагаю вам дождаться подходящей упакованной копии pip 10 от Debian - как говорит @RonnyPfannschmidt , вы не должны использовать pip для обновления своих системных пакетов ...

Похоже, что сценарий Debian pip3 использует внутреннее устройство pip, поэтому получение исправления, совместимого с pip10, определенно зависит от них (и я вполне ожидаю, что они будут ждать выпуска своего пакета pip10, пока они не будут отсортированы).

к дополнительному примечанию - замена системного пипа с помощью пипса всегда является актом системного вандализма, когда тот, кто его вызывает, несет ответственность за последствия

Убедите людей, работающих с debian / ubuntu, не продавать, а затем позволить сгнить половину своих пакетов, и это будет веский аргумент.

Вы можете использовать virtualenv или venv, чтобы изолировать себя от установки системных пакетов.

Вы не должны изменять файлы, управляемые менеджером пакетов (здесь установка системного пакета) - я думаю, они не ожидают, что пользователи будут что-то изменять - вероятно, это не поддерживается Debian. Это обязательно вызовет такие проблемы.

Та же проблема и с Fedora.

Возможно, должен быть канал «бета» или какой-то аналогичный механизм, чтобы люди могли проводить больше тестов перед выпуском, а не просто сбрасывать сломанную версию на pypi и вызывать взрыв всех сборок.

@ fake-name Было сделано два предварительных релиза:

• 10.0.0b1 был выпущен 31 марта.
• 10.0.0b2 был выпущен 2 апреля.

@ fake-name дополнительно общее предложение для использования во всех дистрибутивах - используйте virtualenv, не вандализируйте систему, и это работает - люди просто следуют ему шрифтом, а затем задаются вопросом, когда что-то ломается, и обвиняют pip

было много ручного и автоматического тестирования с помощью virtualenvs, которое работает

также в virtualenv, по крайней мере, не должно быть команды debian made pip3 - так что, черт возьми, вы говорите об этом нарушении в virtualenvs - пожалуйста, предоставьте достаточно данных для фактической проверки вместо того, чтобы ныть о поломках, не предоставляя данные, необходимые для их проверки

pip - это волонтеры, а не компания с десятками сотрудников

~ Удалено ~. путал это с https://github.com/pypa/pip/issues/5220

Я сумасшедший.

Спасибо, не понял, что замена системного пипа - плохая идея, но имеет смысл. Однако было бы хорошо, если бы в этом случае pip не ворчал об обновлении. Возможно ли это? Я считаю, что многие люди (включая меня) просто сделают то, что «вещь» их попросит.

@ fake-name спасибо за дальнейшие действия - это удивительно часто не соответствуют деталям, когда крупный выпуск имеет многогранное влияние и часть его пытается испортить вам день

было бы хорошо UX, если бы pip не пилил бы об обновлении в этом случае

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

Всегда предпочитайте "python3 -m pip" вместо pip3 или даже лучше "/ usr / bin / env python3 -m pip", это безопаснее и позволяет избежать этой проблемы с pip10

Мы решили эту проблему с помощью чистого хеша в bash:

$ hash -d pip

Или в тире (ш):

$ hash -r pip

Также устраните эту проблему при создании образов докеров.

@RonnyPfannschmidt говорит, что «замена системного пипа с помощью пипса всегда является актом системного вандализма, когда тот, кто его вызывает, несет ответственность за последствия», у которого есть 6 больших пальцев вверх. Я считаю это особенно тупым комментарием, учитывая, что я дал указание сделать это самим pip:

_Вы используете pip версии 8.1.1, однако доступна версия 10.0.0.
Вам следует рассмотреть возможность обновления с помощью команды pip install --upgrade pip.

Если этот комментарий имеет какое-то значение, создатели pip должны удалить это сообщение, и я бы посоветовал @RonnyPfannschmidt поднять вопрос на этот счет и

@qacollective - я думаю, аргумент здесь в том, что дистрибутивы взяли pip, изменили его и повторно упаковали в свои репозитории. Таким образом, это не совсем вина Pypi, сообщение все еще там.

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

Лично, по крайней мере, для python на ubuntu, я бы хотел, чтобы они бросили его. Версия практически каждого пакета python в apt варьируется от действительно очень старого до окаменевшего. ИМХО, Apt в принципе бесполезен для python.

FWIW, я обычно считаю, что лучший вариант - никогда не устанавливать дистрибутив в первую очередь, а вместо этого устанавливать его вручную через get-pip.py . Таким образом, у вас не возникнет проблем с диспетчером пакетов платформы, который знает только о некоторых пакетах python.

Всегда используйте --user, чтобы не убить вашу систему

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

Должен обрабатывать большую часть случаев с ошибками и приводить к установке правильной версии pip в ˜/.local/bin .

Я могу подтвердить, что решение

Немного предыстории: после обновления (pip install -U pip) на ванильной ubuntu 16.04 (AWS AMI) возникает следующая ситуация:
$ ПУТЬ = ..: / usr / local / bin: ... : / usr / bin: ...
/ usr / bin / pip по-прежнему является старой / oem-версией (не работает)
/ usr / local / bin / pip - это новый скрипт v10 (отлично работает при прямом вызове)

Несмотря на то, что правильная версия pip предшествует сломанной в PATH, bash все еще запоминает старую, поэтому, когда вы вызываете ее как pip, вы получите старую, сломанную. hash-d pip или hash -r решает проблему.

Во-первых, несколько заметок о том, что здесь произошло в Debian / Ubuntu (и, вероятно, еще в нескольких дистрибутивах Linux):

• pip не поддерживает использование внутренних компонентов путем его импорта. Подробнее об этом в документации здесь .
• Debian (отсюда и Ubuntu) не поддерживает изменение файлов, управляемых менеджером пакетов, с использованием чего-то, что хорошо, не является их менеджером пакетов.

Эта проблема вызвана тем, что оба способа каким-то образом нарушаются.

• Debian использует внутренние методы pip (которые больше не работают из-за реорганизации внутренних компонентов pip). Debian здесь предполагает, что версия pip в их репозиториях - это та, которая будет установлена.
• Запуск pip install --upgrade pip от имени пользователя root без каких-либо других параметров изменяет файлы, которые должны управляться apt, что нарушает работу сценария Debian.

Несколько общих советов по Linux:

• Хорошая привычка - использовать --user за пределами venv.

  pip install --upgrade --user pip
  

• Никогда не запускайте pip с sudo, если вы не знаете, что делаете.

Какое обходное решение?

@standag «s решение полезно , когда это вызвано кэшированием BASh в исполняемых файлах.

hash -r pip # or hash -d pip

Если вы изменили установку pip в диспетчере пакетов ОС (например, с помощью sudo pip ), а python -m pip все еще работает, одним из способов решения проблемы является удаление установленной версии pip и переустановка установленной версии диспетчера пакетов. .

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

Если вы не используете Debian / Ubuntu _и_ pip сломался, попробуйте запустить:

python -m pip install --force-reinstall pip

Если вышеуказанное не решит ваши проблемы, сообщите о новой проблеме.

[отредактировано @pradyunsg : сделать его более актуальным для ссылки на этот комментарий всех, у кого есть похожие проблемы; обновите предложение, включив в него обходной путь удаления / переустановки]

А как насчет решения этой проблемы вне докера? Он сломан в моей обычной системе, и команда hash не распознала pip.
thinkdigital@thinkdigital-HP-Spectre-x360-Convertible:~$ hash -d pip bash: hash: pip: not found

Я нашел pip3 версии 9.0.1, установленный в virtualenv из проекта, скопировал его в свой / usr / bin, и он снова работает. Вот содержимое исполняемого файла pip3 для тех, кто тоже хотел бы исправить это самостоятельно.

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

Я уверен, что все, что вам нужно сделать, это сохранить это в файл с именем pip3, сделать его исполняемым, запустив sudo chmod + x ./pip3, запустить sudo apt remove python3-pip, а затем скопировать его в каталог bin, запустив sudo cp ./pip3 / usr / bin.
Вот необработанный файл для тех, кто просто хочет его скачать и переместить.
pip3.zip

Меня устраивает:
curl https://bootstrap.pypa.io/get-pip.py | sudo python

Извините, но я хотел бы отметить, что запуск кода python curl'd с какого-то веб-сайта с корневым доступом просто ужасающе небезопасен.

Согласен, и я должен отметить, что это не официальная рекомендация по пунктам. Как уже неоднократно указывалось, вы должны использовать свой системный менеджер пакетов для обновления или иного управления установкой системного пакета, а не get-pip или даже саму pip через sudo.

В этом случае не работает версия из системного менеджера пакетов. Четное
после продувки и переустановки.

В чт, 19 апреля 2018 г., 01:53 Пол Мур [email protected] написал:

Согласен, и я должен указать, что это не официальный пип
рекомендация. Как уже неоднократно говорилось, вы должны использовать
ваш системный менеджер пакетов для обновления или иного управления вашим системным пипом
установка, а не get-pip или даже сам pip через sudo.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pip/issues/5221#issuecomment-382660881 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AV-Hfecz8l1NEyq3vsih0DpNP7QYdxuvks5tqFCdgaJpZM4TVEq6
.

Если переустановка системного пакета по-прежнему не работает, проверьте, есть ли у вас pip10 где-нибудь в / usr / local /, и удалите всю папку.

Замена из / usr / bin сработала для меня, хотя я ДУМАЮ, что
тот, который устанавливал системный менеджер пакетов.

[ @pradyunsg обрезал содержимое электронной почты]

@ThinkDigitalRepair Помогает ли следующее?

В других случаях вы захотите передать --user при установке / обновлении пакетов. TBH, в Linux хорошая привычка использовать --user .

pip install --upgrade --user pip

В порядке. Спасибо. Я испортил его, следуя руководству по Jupyter Notebook из их
сайт, который говорит вам обновить pip напрямую. Копирование и вставка без
осознание последствий снова поражает. :(

[ @pradyunsg обрезал содержимое электронной почты]

@ThinkDigitalRepair pip 10, надеюсь, улучшит ситуацию - когда это происходит, он лучше выводит сообщения об ошибках вместо длинного PermissionError.

Закрытие этой проблемы сейчас, так как здесь нет ничего, что можно было бы предпринять со стороны pip.

Любой, кто ищет, как исправить / обойти эту проблему, может взглянуть на https://github.com/pypa/pip/issues/5221#issuecomment -382069604.

@pradyunsg во многих случаях решения, указанные в этом комментарии, не работают. В свежем Ubuntu 17.10 запустите pip install --upgrade pip : после этого команда pip будет сломана, и решения из комментария не исправят ее. И они не должны!

Если в системе установлен pip 9 с установленным пользователем pip 10, сценарий системы pip пытается импортировать main () из пользовательского pip 10 с неправильным путем импорта. Hash -r или -d не исправит этого, потому что команда pip по-прежнему будет запускать системный pip по умолчанию. И ни один из них не исправит это при обновлении пользовательского пипа, так как системный пип по-прежнему будет 9, пользовательский пип по-прежнему будет 10, поэтому импорт будет продолжать терпеть неудачу.

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

• python -m pip uninstall pip --user , сохраняя системный пункт, который старше

или

• sudo apt remove python-pip и оставьте установленный пользователем pip, который по умолчанию не будет доступен при запуске pip в терминале. Вам нужно будет либо запустить его с помощью python -m pip , либо добавить пути к вашему PATH env var и т. Д.

Все это применимо к обоим pip под Python 2 и 3.

Во всех моих системах Ubuntu (16.04, 17.10. 18.04) у меня есть системный пип для старой версии, а у пользователя пип 10, и я никогда не вижу вашей ошибки импорта.
Вы уверены, что у вас нет поврежденной системы?

@gsemet вы, вероятно, добавили ~/.local/bin в свой PATH env var (или, возможно, использовали другую, более умную оболочку, чем bash по умолчанию), поэтому, когда вы запускаете pip он использует установленный пользователем скрипт pip 10, а не система установила скрипт pip 9. В Ubuntu по умолчанию это не так. Конечно, это можно сделать, и я бы хотел, чтобы так было по умолчанию. Но по умолчанию команда pip вызывает установленный системой pip, даже если он у вас установлен пользователем.

Как воспроизвести это при новой установке Ubuntu 17.10, включая доказательства того, что команды в комментарии 5221 не могут исправить это, и то, что я предложил, исправляет это.

Установка обоих пипсов (системного и пользовательского), что нарушает команду пипса:

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

Как видите, команда pip по умолчанию указывает на системный пип, а не на установленный пользователем.

Команды из указанного комментария, свидетельствующие о том, что они не устраняют проблему:

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

Как видите, пока оба пункта установлены и команда pip указывает на системный пункт (поведение по умолчанию в Ubuntu), проблема не исчезнет.

Исправить вариант 1:

Удалите системный пип, оставьте пользовательский пип, который по умолчанию недоступен с помощью команды pip (поэтому вам нужно использовать 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)

Вы можете добавить ~/.local/bin в переменную окружения PATH, чтобы иметь возможность использовать команду pip с пользовательским пипом.

Исправить вариант 2:

Удалите пользовательский пип, оставьте системный пип, который старше, но по умолчанию имеет рабочую команду pip в пути.

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 Конечно, это необходимо для поддержки устанавливаемого пользователем пакета pip install --user. Но я думаю, что следует сказать пользователям: «Если вы хотите принудительно обновить пакет pip 10 до обновления пакета debian / ubuntu, вам нужно использовать pip install --user --upgrade pip и убедиться, что $HOME/.local/bin находится на вашем пути .Это просто сделать.

@gsemet Я согласен, пользователям следует

@fisadev Большое спасибо. Исправить вариант 1 действительно помогает.

@RonnyPfannschmidt

замена системного пипа с помощью пипса всегда является актом системного вандализма, когда тот, кто его вызывает, несет ответственность за последствия

это комментарий ментального вандализма. Как если бы человек, выполняющий (наивное) обновление, намеренно решил повредить свою собственную установку ... Если бы это было так, тогда сам pip не должен приставать к пользователю обновляться с 9.0.1 до 10.0.1 с каждым одна команда pip выполнена. Я сам последовал этой рекомендации и оказался в этой неразберихе.

К счастью:
sudo python -m pip install pip==9.0.1
было достаточно простым лекарством.

Однако обвинять жертву - это не ответ.

Привет, @ rod-app!

Если бы это было так, то сам pip не должен был призывать пользователя к обновлению с 9.0.1 до 10.0.1 с каждой выполненной командой pip.

Мы заметили это и работали с поставщиками ОС, чтобы избежать этого в будущих версиях pip. - №5346.

Чтобы решить проблему, я побежал ...

sudo geany -i /usr/bin/pip

... и отредактировал предоставленный debian / usr / bin / pip, заменив его на ...

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

и эквивалент для / usr / bin / pip3 (обратите внимание, что вместо этого вызывается python3).

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

... который возвращает полную функциональность pip, несмотря на то, что в моих пакетах сайта установлена ​​версия 10. Я предполагаю, что это будет длиться ровно столько, сколько потребуется debian, чтобы исправить это (или повторно сломать его), отправив обновленный пакет python-pip. Почему они вообще не использовали пакет main, я не знаю.

Официальная версия

Версия pip, установленная в .local/bin/pip показанная ниже, немного интереснее и включает некоторую замену для удаления расширений -script, .py, .pyw и .exe из переданных аргументов, но я не знаю, что это значит или зачем мне это нужно, поэтому для простоты я оставил как указано выше.

#!/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())

Я нашел несвязанную причину этой проблемы с pip v10. При обновлении pip с использованием очень старого системного pip (v1.5.6 в Debian Jessie, т.е. oldstable), для которого по умолчанию используется --system, я заметил, что были установлены неправильные сценарии, например /usr/local/bin/pip содержащие from pip import main - который я нашел, просмотрев файлы. Я предполагаю, что это связано с тем, что старый пакет (или, возможно, установочные пакеты, которые он использует) неправильно устанавливает файл .whl.

python -m pip install --force-reinstall pip исправил это.

5599 предоставляет информацию и предоставляет единое место для поиска помощи в решении этой проблемы для конечных пользователей.

Раздел комментариев к этому вопросу открыт для пользователей, чтобы обсудить конкретные проблемы и решения. :)