Pip это альтернатива easy_install, а как говорят сами разработчики - замена.
Как известно easy_install только часть глыбы под названием setuptools. Много копий сломано по поводу нужно ли такие двухголовое чудовище, которое позволяет продвинутым образом собирать питонячьи пакеты и их устанавливать. Или достаточно стандартного distutils. Вот тут pip выступает как противоположность, говоря - я сборкой пакетов не занимаюсь, а только их ставлю.
Pip может поставить любой пакет собранный при помощи distutils. Причем только source-пакет - никаких бинарных яиц ему и прочих setuptools'овых прибамбасов.
Эта концептуальная простота во многом помогла pip постепенно выйти на уровень широко используемого инструмента в питон-сообществе. Благо и пользоваться им максимально просто:
# pip install wna
где wna - это некий пакет (для примера я возьму код своего блога).
Так же преимуществом pip безусловно является более полезный вывод информации о процессе установки и репортинг ошибок во всяких непредвиденных ситуациях.
Помимо уже собранных source-пакетов pip может брать исходники пакетов из систем контроля версий. Поддерживаются subversion, mercurial, git, bazaar. Делая checkout и устанавливая через python setup.py с ключом devel, дает возможность иметь в папке /src/packet_name/ исходный код и при необходимости редактировать его.
# pip install -e hg+http://bitbucket.org/daevaorn/turbion/#egg=turbion
Где egg=turbion говорит pip чтобы он сделал checkout в /src/turbion/.
Очень полезная возможность, когда некоторые пакеты. которые вы используете актуальнее брать из VCS чем ждать релизов. Так я, например, поступаю с Джангой.
Для меня одной из самых востребованных фичей pip является возможность задать внешние дополнительные пакеты/зависимости при установки того или иного базового пакета. Для этого существует так называемые requirements files. Это обычный текстовый файл на каждой строчке которого находятся название пакетов и опционально версия или путь до репозитория. Вот пример такого файла, который я использую для своего блога:
-e svn+http://code.djangoproject.com/svn/django/trunk#egg=Django
-e svn+http://django-filebrowser.googlecode.com/svn/trunk#egg=Filebrowser
Djapian==2.2.3
django-dbtemplates
postmarkup
-e hg+https://daevaorn@bitbucket.org/daevaorn/django-composition/#egg=django-composition
-e hg+https://daevaorn@bitbucket.org/daevaorn/django-shoes/#egg=django-shoes
Устанавливая теперь свой блог, я пишу:
# pip install wna -r requirements.txt
Суть таких внешних файлов в том, что их может быть несколько заточенный под какое-то свое окружение. Распространяться они могут совместно с пакетом или совсем отдельно. Допустим я хочу по максимуму использовать возможности какого-то пакета и перечислю там пять зависимостей, а вот если я хочу только базовый функционал, то могу ограничится некоторыми из них. Тем самым я даю возможность самому пользователю выбрать вариант установки и не заставлю его в обязательном порядке тянуть конкретные зависимости.
Конечно в большинстве случает нужен дефолтный вариант зависимостей, который будет жестоко прописан в самом setup.py, но и иметь более гибкую систему установки сторонних сущностей тоже бывает полезно.
Мне лично это помогает устанавливать одно и тоже приложение в разных виртуальных окружениях, где по исторически сложившимся обстоятельствам разные версии необходимых библиотек.
Поскольку Ян Бикинг автор как pip так и virtualenv, то вполне естественно что они могут взаимодействовать. Выражается это в том, что pip может ставить пакеты в указанное окружение, создав предварительно, если его не существует. Для этого используется ключ -E:
# pip install wna -E ./blogenv
Удобство, тут в том, что не надо запускать pip с бинарником питона из этого окружения явно.
В дополнение pip ещё предлагает так называемый фризинг (freezing) - это когда он создает на основе текущих установленных пакетов в системе специальный requirements.txt файл. Который потом можно использовать для "повторения" текущей установки где-то ещё:
# pip freeze requirements.txt
# cd где-то_ещё
# pip install requirements.txt
Ещё более радикальная возможность "взять с собой" - это создать бандл (bundle). Бандл это архив, который содержит установленные пакеты в системе, который тоже можно притащить в другое место и, распаковав, получить то же самый набор пакетов, но уже в новой системе/окружении:
# pip bundle my.pybundle Django markdown2 pytils
# cd где-то_ещё
# pip install my.pybundle
Что мне ещё нравится в pip это предсказуемость интерфейса использования, к которому быстро привыкаешь и начинаешь достаточно быстро пользоваться.
Так что всем всячески рекомендую использовать именно pip для установки питонячих пакетов.
Комментарии 15
А я вот, в последнее время, съехал с pip на buildout. По крайней мере, когда нужно что-то более сложное, нежели просто установка одного-двух пакетиков для "поиграться".
Кроме того, buildout позволяет наследовать конфиги, что оказывается очень удобно: есть базовый конфиг, где описано общее окружение, и есть, скажем, конфиги для тестинга и разработки, которые что-то переопределяют. Например докидывают пакетиков типа ipython или django-debug-toolbar.
Все три своих сайта сейчас именно так раскладываю в продакшн.
Оставлен 23 Июнь 2009 в 12:07 ¶при наличии deb, pip не нужен, т.к. в системе есть не только python, чаще всего
Оставлен 23 Июнь 2009 в 13:04 ¶@lig это спорное утверждение.
Попробуйте собрать на deb пакетах виртаульное окружение, чтобы запустить на одной машине одновременно два сервиса, которые будут требовать, скажем, разные версии SQLAlchemy. Опакечивать их отдельно, и как-то раскладывать в разные места, конечно, можно, но со временем это превратится в сущий ад.
Оставлен 23 Июнь 2009 в 13:15 ¶@Alexander_Artemenko т.е. вы утверждаете, что pip функциональнее deb? это точно не так
пусть требуют всё что им угодно, всё это поставится и будет предоставлено каждому пакету, по его потребностям
только сегодня собрал и установил Python 2.6 deb-пакетом. отлично встал и не мешает 2.5
А ещё есть aptitude, в котором отлично видно состояние того, что у вас сейчас установлено и что от чего зависит.
А еще есть debhelper, который помогает делать с вашими deb-пакетами то, что нужно именено вам...
Оставлен 23 Июнь 2009 в 14:41 ¶@lig о том, что такое deb пакеты, я знаю непонаслышке. Я утверждаю лишь то, что virtualenv + pip или тот же buildout позволяют решать некоторые проблемы, которые трудноразрешимы с помощью дебиановской системы пакетов.
Конечно, когда вы полностью контролируете окружение, deb пакеты хороши. Но представьте на секундочку, что вы работаете в команде, и какой-нибудь архаровец выкатывает на продакшн сервер версию обратно-несовместимую библиотеки, которую вы используете.
В случае с deb пакетами, у вас будет несколько вариантов:
Последние два варианта далеко не быстрые, а первый, избавляет от проблемы лишь временно. И всего этого можно было бы избежать, используя изолированные виртуальные окружения для каждого из проектов.
Я не агитирую против использования debian пакетов, это хорошо и правильно, в Яндексе ведь не зря они используются. Но все-таки есть и другие средства, которые могли бы значительно облегчить нашу с вами жизнь.
Оставлен 23 Июнь 2009 в 14:58 ¶@Alexander_Artemenko у меня на продакш права имеют только администратор экплуатационной площадки и я. я ничего сам туда не делаю.
прежде чем попасть на эксплуатационную всё тестируется на тестовой (простите за тафтологию) площадке
ничего "срочно" на продакшене не может произойти, потому что люди специально для этого работают, сначала тестируют, а потом следят, как автоматика обрабатывает deb-ки очередной версии ПО в процессе деплоя на продакшн
никто не мешает использовать изолированные окрудения в рамках apt, никто не мешает использовать openvz или ещё чего-нибудь
я не агитирую против pip, я агитирую против размножения архитектурных костылей
Оставлен 23 Июнь 2009 в 15:14 ¶кстати про apt: я совсем забыл мой извечный главный довод.
apt может удалить установленное deb-пакетом ПО, как будто его не было, а pip - нет.
отсюда куча геморроя и хвостов старого ПО в системе
Оставлен 23 Июнь 2009 в 16:35 ¶Если использовать virtualenv, то никаких "хвостов" не остается. Это не проблема. А тот же buildout, умеет за собой рецепты удалять, если конечно они это поддерживают.
Оставлен 23 Июнь 2009 в 17:57 ¶По мне так deb пакеты во многих случаях просто overkill и нет смысла с ними заморачиваться.
Да, это мощнейший инструмент, но он зачастую не нужен и излишен.
Плюс, Art абсолютно прав, что создавать виртуальные окружения очень ценная возможность как pip + virtualenv так и buildout. Таких же доступных решений для deb системы нет.
Ну и конечно deb пакеты так или иначе привязывают к Debian окружению, что далеко не всех устраивает.
Оставлен 23 Июнь 2009 в 20:09 ¶Кстати, возможно, и для debian есть способ запускать что-либо в "виртуальном" окружении. Таким способом pbuilder собирает пакеты. Правда такое окружение будет скорей всего на диске будет уж очень много места занимать.
Оставлен 23 Июнь 2009 в 23:58 ¶Интересная тема. Сегодня, изучая данную тулзу, был озадачен тем что если использовать ключ --no-site-packages и попытаться вывести список установленных пакетов, то их количество такое же что если не использовать ключ --no-site-packages. То есть мои действия:
и точно такой же размер файла и без этого ключа. Но как я понял по доке как раз данная опция отключает "сбор информации" с "центрального каталога" про установленные пакеты?
Что же происходит тогда? Почему pip видит установленные пакеты, которые были запрещены для данного окружения опцией --no-site-packages
Спасибо.
Оставлен 22 Март 2010 в 01:13 ¶Рома, не вижу чтобы ты указывал ключ
Оставлен 22 Март 2010 в 15:25 ¶--no-site-packages. Ты уверен, что всё делаешь правильно?Действительно я сделал опечатку в своем комментарии (не написал ключ --no-site-packages), но в консоль я действительно ввожу это ключ. Вот сейчас туже операцию провел на другом компе. Вот лог из консоли:
Но "окно в внешний мир" не закрылось
Спасибо
Оставлен 23 Март 2010 в 11:21 ¶Саша я разобрался в данной проблеме. Можно не размещать мои комменты по этой теме.
Оставлен 23 Март 2010 в 11:36 ¶Но все таки оно берет из "внешнего мира" пакеты, хотя в каталоге локалного окружения каталог "site-packages" там пакетов нет, которые выводит pip freeze. :(
Оставлен 23 Март 2010 в 15:09 ¶Оставьте комментарий