Задать вопрос
font
@font
В поисках самого лучшего

PIP или esay_install: что лучше?

Привет.
Многие мне не рекомендуют использовать easy_install.
«В PIP быстрее появляются обновления», -- говорит один.
«Есть опция деинсталяции», твердит следующий.
«PIP -- это полная замена easy_install», -- утверждают сами разработчики.
Вопрос.
В чем правда? Почему лучше одно, а не другое и что используете вы для контроля пакетами?
  • Вопрос задан
  • 3082 просмотра
Подписаться 3 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 7
mututunus
@mututunus
Backend developer (Python, Golang)
Однозначно pip!
Ответ написан
Комментировать
@lPolar
data scientist
кстати как вариант можно попробовать conda. Из плюсов - большую часть пакетов берет уже скомпилированными. Из минусов - не все пакеты в ней есть.
Ответ написан
Комментировать
@SandeR_WW
easy_install doesn't support uninstalling
Ответ написан
Комментировать
opium
@opium
Просто люблю качественно работать
на взгляд сисадмина и то и другое от лукавого
логично что по возможностям и популярности рулит пип и надо юзать в данной дилеме его
Ответ написан
Комментировать
donkaban
@donkaban
Умею рисовать тени
pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U
Ответ написан
pip не требует админ прав для установки библиотек.
easy_install не умеет удалять.
Выбор уже, очевиден.
Ответ написан
sumej
@sumej
DevOps
Я пользуюсь pip. Тем не менее есть много подводных камней, примеры в статье "Почему я ненавижу virtualenv и pip перевод":
pip каждый раз собирает из исходников

Кажется, pip умышленно был лишён возможности easy_install устанавливать пакеты из бинарников (eggs). Несмотря на то, что распространение бинарников было значимой частью python-платформы и, кстати, вполне работоспособной, видимо, кто-то решил, что это плохая идея. Конечно, с точки зрения разработчиков, компиляция пакетов из исходников есть очевидное благо, которое позволяет им не компилировать предварительно пакет под каждую из всех поддерживаемых платформ (а переложить это на несомненно обрадованного этим пользователя — прим. пер.). Но компиляция становится злом в том случае, если целевых платформ немного, и вы точно знаете её/их и хотели бы собрать пакет заранее, избавившись от необходимости иметь компилятор на целевом компьютере

Этот чёртов requirements.txt

Те разработчики, которые пишут лишь приложения, не вполне понимают все особенности создания пакетов, поэтому, недолго думая, просто «захардкоживают» весь ассортимент используемых ими модулей в своё приложение, просто перечисляя их в requirements.txt, ведь это так удобно! Эти разработчики чаще всего просто советуют пользователям установить venv, а затем накатить в него свой пакет командой pip install -r requirements.txt.

В результате мы имеем некоторое количество python-разработчиков, которые считают requirements.txt панацеей от всех проблем. Они даже никогда не узнают о существовании setuptools. Их легко покоряет кажущимся простым тупое перечисление ссылок на необходимые пакеты, лежащие где-то в недрах интернета: на сайтах или в системах контроля версий. Меня обескураживает их святая уверенность в «фантастической» прагматичности этого подхода и вытекающем отсюда желании пропагандировать использование virtualenv+pip как связки незаменимых инструментов для всех и каждого.

URI в качестве путей к зависимостям это отстой

setuptools позволяет вам указать имя и необходимую версию пакета, который по умолчанию скачивается с Pypi. Pypi обеспечивает индексацию, но вы можете создать и свой собственный индекс (в виде простых HTML страниц) и указать, что информацию следует извлекать в первую очередь из них, а не с сайта Pypi. Кто бы ни разработал эту технологию, он пытался предоставить разработчику возможность привязываться к именам пакетов, а не их физическому местоположению или веб-протоколу. И он мыслил правильно.
Если вы в requirements.txt указываете путь к локальному файлу или к лежащему на каком-нибудь сайте тарболлу, по факту вы захардкоживаете эту ссылку. Хотя в данном случае лучшим выходом было бы использование репозитория пакетов. Который позволил бы людям, например, настроить зеркала на него в своей локальной сети. Кроме того, вы не можете указать минимальную версию, лишь только точную текущую. А в один прекрасный день тот самый файлик с пакетом переместится или удалится, в общем, пропадёт, и код внезапно перестанет работать. Совершенно очевидно, что мы этого не хотим, ведь так?

Если вам по нраву pip freeze, с вами что-то не так
У меня хорошо получается отслеживать свои зависимости и управлять ими. Я делаю это с помощью pip freeze. Команду pip freeze используют для того, чтобы убедиться, что никакие Python-зависимости не были упущены посреди цикла разработки. Если вы полагаете, что pip freeze выдаёт вам список зависимостей как раз для вставки в requirements.txt (который, напомню, не нужен) — тогда вы просто используете --no-site-packages (который тоже не нужен) при создании нового venv, и весь набор зависимостей всё равно получается глобально-системным, а не питоньим. А, и кроме того, таким образом не узнать, какие из ваших зависимостей установлены напрямую, а какие подтянуты другими.

и что используете вы для контроля пакетами?

pip вполне подойдет.
Установить пакет pip install MyProject
Обновить пакет pip install --upgrade MyProject
Установить определённую версию пакета pip install MyProject==1.0
В общем:
Usage:
  pip <command> [options]

Commands:
  install                     Install packages.
  uninstall                   Uninstall packages.
  freeze                      Output installed packages in requirements format.
  list                        List installed packages.
  show                        Show information about installed packages.
  search                      Search PyPI for packages.
  wheel                       Build wheels from your requirements.
  zip                         DEPRECATED. Zip individual packages.
  unzip                       DEPRECATED. Unzip individual packages.
  help                        Show help for commands.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы