Что такое pip?

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 для установки питонячих пакетов.

Комментарии 20

  1. Alexander Artemenko написал:

    А я вот, в последнее время, съехал с pip на buildout. По крайней мере, когда нужно что-то более сложное, нежели просто установка одного-двух пакетиков для "поиграться".

    Кроме того, buildout позволяет наследовать конфиги, что оказывается очень удобно: есть базовый конфиг, где описано общее окружение, и есть, скажем, конфиги для тестинга и разработки, которые что-то переопределяют. Например докидывают пакетиков типа ipython или django-debug-toolbar.

    Все три своих сайта сейчас именно так раскладываю в продакшн.

    Оставлен 23 Июнь 2009 в 12:07
  2. lig написал:

    при наличии deb, pip не нужен, т.к. в системе есть не только python, чаще всего

    Оставлен 23 Июнь 2009 в 13:04
  3. Alexander Artemenko написал:

    @lig это спорное утверждение.

    Попробуйте собрать на deb пакетах виртаульное окружение, чтобы запустить на одной машине одновременно два сервиса, которые будут требовать, скажем, разные версии SQLAlchemy. Опакечивать их отдельно, и как-то раскладывать в разные места, конечно, можно, но со временем это превратится в сущий ад.

    Оставлен 23 Июнь 2009 в 13:15
  4. lig написал:

    @Alexander_Artemenko т.е. вы утверждаете, что pip функциональнее deb? это точно не так

    пусть требуют всё что им угодно, всё это поставится и будет предоставлено каждому пакету, по его потребностям

    только сегодня собрал и установил Python 2.6 deb-пакетом. отлично встал и не мешает 2.5

    А ещё есть aptitude, в котором отлично видно состояние того, что у вас сейчас установлено и что от чего зависит.

    А еще есть debhelper, который помогает делать с вашими deb-пакетами то, что нужно именено вам...

    Оставлен 23 Июнь 2009 в 14:41
  5. Alexander Artemenko написал:

    @lig о том, что такое deb пакеты, я знаю непонаслышке. Я утверждаю лишь то, что virtualenv + pip или тот же buildout позволяют решать некоторые проблемы, которые трудноразрешимы с помощью дебиановской системы пакетов.

    Конечно, когда вы полностью контролируете окружение, deb пакеты хороши. Но представьте на секундочку, что вы работаете в команде, и какой-нибудь архаровец выкатывает на продакшн сервер версию обратно-несовместимую библиотеки, которую вы используете.

    В случае с deb пакетами, у вас будет несколько вариантов:

    • срочно откатить пакеты коллеги, и потом долго с ним ругаться;
    • срочно пофиксить свой проект (хорошо если он один), чтобы он был совместим с новой версией;
    • сделать две версии пакета с либой, да еще такие, которые встанут на систему параллельно и не будут друг другу мешать.

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

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

    Оставлен 23 Июнь 2009 в 14:58
  6. lig написал:

    @Alexander_Artemenko у меня на продакш права имеют только администратор экплуатационной площадки и я. я ничего сам туда не делаю.

    прежде чем попасть на эксплуатационную всё тестируется на тестовой (простите за тафтологию) площадке

    ничего "срочно" на продакшене не может произойти, потому что люди специально для этого работают, сначала тестируют, а потом следят, как автоматика обрабатывает deb-ки очередной версии ПО в процессе деплоя на продакшн

    никто не мешает использовать изолированные окрудения в рамках apt, никто не мешает использовать openvz или ещё чего-нибудь

    я не агитирую против pip, я агитирую против размножения архитектурных костылей

    Оставлен 23 Июнь 2009 в 15:14
  7. lig написал:

    кстати про apt: я совсем забыл мой извечный главный довод.

    apt может удалить установленное deb-пакетом ПО, как будто его не было, а pip - нет.

    отсюда куча геморроя и хвостов старого ПО в системе

    Оставлен 23 Июнь 2009 в 16:35
  8. Alexander Artemenko написал:

    Если использовать virtualenv, то никаких "хвостов" не остается. Это не проблема. А тот же buildout, умеет за собой рецепты удалять, если конечно они это поддерживают.

    Оставлен 23 Июнь 2009 в 17:57
  9. Александр Кошелев написал:

    По мне так deb пакеты во многих случаях просто overkill и нет смысла с ними заморачиваться.

    Да, это мощнейший инструмент, но он зачастую не нужен и излишен.

    Плюс, Art абсолютно прав, что создавать виртуальные окружения очень ценная возможность как pip + virtualenv так и buildout. Таких же доступных решений для deb системы нет.

    Ну и конечно deb пакеты так или иначе привязывают к Debian окружению, что далеко не всех устраивает.

    Оставлен 23 Июнь 2009 в 20:09
  10. Alexander Artemenko написал:

    Кстати, возможно, и для debian есть способ запускать что-либо в "виртуальном" окружении. Таким способом pbuilder собирает пакеты. Правда такое окружение будет скорей всего на диске будет уж очень много места занимать.

    Оставлен 23 Июнь 2009 в 23:58
  11. Romankrv написал:

    Интересная тема. Сегодня, изучая данную тулзу, был озадачен тем что если использовать ключ --no-site-packages и попытаться вывести список установленных пакетов, то их количество такое же что если не использовать ключ --no-site-packages. То есть мои действия:

    $ virtualenv myenv
    $ cd myenv
    $ source bin/activate
    $ pip freeze > req.tx
    
    -rw-r--r-- 1 r r 1395 2010-03-21 23:57 file.tx
    

    и точно такой же размер файла и без этого ключа. Но как я понял по доке как раз данная опция отключает "сбор информации" с "центрального каталога" про установленные пакеты?

    Что же происходит тогда? Почему pip видит установленные пакеты, которые были запрещены для данного окружения опцией --no-site-packages

    Спасибо.

    Оставлен 22 Март 2010 в 01:13
  12. Александр Кошелев написал:

    Рома, не вижу чтобы ты указывал ключ --no-site-packages. Ты уверен, что всё делаешь правильно?

    Оставлен 22 Март 2010 в 15:25
  13. Romankrv написал:

    Действительно я сделал опечатку в своем комментарии (не написал ключ --no-site-packages), но в консоль я действительно ввожу это ключ. Вот сейчас туже операцию провел на другом компе. Вот лог из консоли:

    $ virtualenv myenv --no-site-packages
    New python executable in myenv/bin/python
    Installing setuptools............done.
    $ cd myenv/
    $ source bin/activate
    $ pip freeze
    BeautifulSoup==3.1.0.1
    Brlapi==0.5.3
    BzrTools==2.0.1
    CherryPy==3.1.2
    

    Но "окно в внешний мир" не закрылось

    Спасибо

    Оставлен 23 Март 2010 в 11:21
  14. Romankrv написал:

    Саша я разобрался в данной проблеме. Можно не размещать мои комменты по этой теме.

    Оставлен 23 Март 2010 в 11:36
  15. Romankrv написал:

    Но все таки оно берет из "внешнего мира" пакеты, хотя в каталоге локалного окружения каталог "site-packages" там пакетов нет, которые выводит pip freeze. :(

    Оставлен 23 Март 2010 в 15:09
  16. Max Sinelnikov написал:

    Спасибо за статью, очень понравился pip. Вставлю свои пять копеек в спор вокруг pip vs deb. Беда с дебианом в том, что на продакш вы не потащите ни анстейбл, ни тестинг. А то что есть в стейбл, как правило, устарело за полгода до релиза стейбл. Поэтому без virtenv ну очень тяжко, сейчас заворачиваем виртуальные окружения в deb-пакеты, но вcе это как-то костыльно. А вот pip bundle, похоже, то что нужно

    Оставлен 10 Апрель 2011 в 17:12
  17. Александр Кошелев написал:

    Беда с дебианом в том, что на продакш вы не потащите ни анстейбл, ни тестинг. А то что есть в стейбл, как правило, устарело за полгода до релиза стейбл.

    Не согласен. Если и не подключать внешние не stable репозитории, то никто не машает сдалть вам свой "корманный" stable с избранными пакетами свежих версий нужных вам библиотек. Так же любую библиотеку можно пересобрать со свежими исходниками самим.

    Оставлен 11 Апрель 2011 в 00:15
  18. Max Sinelnikov написал:

    Можно так, в конце-концов имеено в такой "карманный стейбл" я и кладу свои деб-пакеты. Можно туда же положить и новую версию используемого фреймворка с его зависимостями. Но почему-то в итоге постоянно получается так, что в этом карманном стейбле оказывается 20-30 различных пакетов, за которыми надо следить, обновлять, пересобирать и, по-хорошему, тестировать. У меня так и не дошли руки автоматизировать всё это, поэтому я забил и пока деплою пакет с готовым протестированным окружением.

    Оставлен 22 Апрель 2011 в 15:11
  19. http://www.akamit.com/blog/ написал:

    Кроме дебиана есть ещё и другие ОС, где нет deb'ов.

    Оставлен 14 Сентябрь 2011 в 16:51
  20. Maxim Syabro написал:

    Александр, это уже жуткий оверхед )

    Оставлен 18 Сентябрь 2011 в 21:37