Почему не стоит использовать sudo pip?

#python #ubuntu #pip

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

Ответы

Ответ 1

Почему НЕ стоит использовать sudo pip install?

При установке пакета вы не просто размещаете его в своей файловой системе, но и выполняете
скрипт setup.py. Поскольку в PyPI загрузить пакет может кто угодно, вы не можете быть
уверены, что setup.py не содержит код, выполнение которого под пользователем root нежелательно/опасно/недопустимо.

По уровню опасности это равносильно выполнению под суперпользователем shell-скрипта
"из облака":

wget -O - http://example.com/some/unsafe/script.sh | bash


Как же быть?

Вариант 1

Кроме случаев, когда вам крайне необходимо установить пакет из-под root-а, вы можете
использовать

pip install --user mypackage


чтобы установить пакет в репозиторий текущего пользователя $HOME/.local/lib/pythonx.y/site-packages/.  

Вариант 2

Использовать изолированные окружения, например virtualenv. В этом случае у вас под
рукой будет неограниченное количество рабочих окружений (например, под каждый проект,
с разными версиями python), которые не будут мешать друг другу.

Пакеты будут храниться в $HOME/.virtualenvs/$ENVNAME/lib/pythonx.y/site-packages/
вместе с нужной версией python и сторонними бинарниками, а переключение окружений выполняется
командой workon $ENVNAME.

IDE, вроде PyCharm, знают про виртуальные окружения и умеют с ними работать.


Ответ 2

Основная причина та же почему virtualenv существует: если у вас есть Питон-пакеты
foo, bar, которые требуют разные версии libbaz библиотеки, то sudo pip install bar
может обновить версию libbaz, сломав foo пакет, ожидающий более старую версию из системных
пакетов.

Гипотетический cценарий, но с реальными пакетами: допустим у вас стоял python-matplotlib
Ubuntu пакет и вы обновили его до PyPI версии, используя sudo pip. На первый взгляд
всё замечательно, вы успешно построили желаемый график. Через пару дней вы обнаружили,
что поиск книг в calibre стал неустойчиво работать (не можете найти книгу по запросу,
который раньше её находил). Потратив какое-то время на отладку проблемы, если вам повезёт,
то вы сможете локализовать её к проблеме с версией pyparsing модуля, используемого
как в calibre так и в matplotlib.

То есть проблема с sudo pip install matplotlib -U не в том, что код с PyPI выполняется
от имени root (c точки зрения безопасности, проблемы хуже, чем с sudo apt-get install
python-matplotlib, но не особо для типичного разработчика -- можно даже gpg-подпись
проверить для скаченного matplotlib wheel, если есть желание).

Проблема в том, что sudo pip к трудно диагностируемым проблемам может вести из-за
несоответствия ожидания пакетов, упакованных для apt-get и версий пакетов с PyPI. 

Именно поэтому, пакеты, которые должны быть особенно независимы, такие как pip, pkg_resources
используют свою локальную копию:  ._vendor.pyparsing.

Иногда можно использовать радикальных подход и ставить каждую утилиту в своё virtualenv,
к примеру, используя pipsi команду:

$ pipsi install youtube-dl


Это позволяет обновлять youtube-dl, не трогая пакеты, которые могут использоваться
другим ПО на системе. И обратное, обновление других пакетов не сломает youtube-dl команду.

Недостаток подобного подхода в том, что при исправлении дырки в безопасности в какой-нибудь
зависимости, её придётся обновлять в каждом virtualenv отдельно.

По сути, используя sudo pip, вы берёте на себя ответственность о том, что все установленные
вами версии пакетов и их зависимости будут совместимы с пакетами, установленными системным
менеджером пакетов сейчас и в будущем. Обычно это работа создателей Linux дистрибутивов,
типа Ubuntu -- они стараются, чтобы версии пакетов, распространяемые в дистрибутиве,
работали бы друг с другом.

Устанавливая pip install --user , вы не сломаете программы, которые от другого
пользователя запускаются. Ставя в virtualenv,  вы изолируете систему от возможных изменений
и наоборот (если --system-site-packages опция не указана при создании) изолируете пакеты
внутри virtualenv от изменений в системе.

Для удобства управления virtualenv, можно virtualenvwrapper поставить.


Ответ 3

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

Если не получается установить какой-то пакет без root'а, то, вероятно просто неверно
выставленно разрешение на директорию с пакетами python