Совместное использование PyPI и системного менеджера пакетов
2007-12-19 23:47Во всех современных дистрибутивах существуют менеджеры управления пакетами и уже собранные пакеты для языка python. К сожалению, этих пакетов невообразимо меньше, чем доступных в репозитории питоновских модулей PyPI, да и качество их, зачастую, оставляет желать лучшего. Поэтому, если вы разработчик и активный участник пайтон-сообщества, то я рекомендую используя PyPI ухитрится поддерживать свою личную рабочую область. Представители команд, поддерживающих дистрибутивы, уверяют нас в невозможности этого. Но ... не врут ли они?
Ну а если вам нужны поставки, массовые установки и т.п. - то эта статья и аргументация не для вас: в таких случаях нужно договариваться с дистрибутивом и решать проблемы там.
Как выжить питонисту в кривом дистрибутиве
Введение в проблему
На сегодняшний день практически все дистрибутивы оснащены продвинутыми менеджерами пакетов, позволяющими без особых раздумий установить сложную конфигурацию системы. Тем не менее, хотя прогресс не стоит на месте, все эти средства обладают рядом недостатков (неполнотой контроля завивисимостей, отсутствием автоматической сборки зависимостей, некорректно собранными пакетами (с неправильными опциями), сборка пакетов непрофессионалами и др.). Эти недостатки редко в наличии все вместе (прогресс все-таки есть), но по-немногу они есть везде.
Из-за особенностей питона и самого сообщества питонистов эти недостатки сильно усиливаются, делая жизнь питониста в дистрибутиве невозможной.
Особенности python-комьюнити
Питон изначально развивается как системно-независимый язык. Удивительно, но факт: этот язык породил системно-независимый набор инструментария, и даже системно-независимое сообщество. Каждый раз, когда я провожу семинар по темам, связанным с питоном, я выступаю перед аудиторией, на ноутах которой стоят не только различные клоны линукса, но и freebsd, macos и даже тот-кого-не-надо-называть - windows. И ни у кого из них практически не возникает проблем с выполнением упражнений и заданий семинара.
Более того, я видел такие-же мультиплатформенные компании, и, хотя, это требует от них определенной дополнительной дисциплины, тем не менее, я думаю об этом как о первом случае достаточно перспективного явления.
Главная особенность python-комьюнити - платформо-независимость. И это надо учитывать: тот, кто начинает работать на конкретную платформу отрывается от python-комьюнити.
Частное следствие из этого утверждение: любая distribution-team скорее всего не содержит в себе хороших python-специалистов.
Особенности самого python
Питон язык весьма изменчивый (даже минорные версии слабо совместимы между собой), зато его пакетная база покрывает потребности настолько, что можно собрать дистрибутив, состоящий только из питона - от веб-серверов до IDE-сред. И это будут не какие-то поделки, зачастую, это промышленные решения, способные легко обогнать то, что лежит в дистрибутивах.
Python, несмотря на некоторую концептуальную слабость самого языка полон новыми концепциями в своих пакетах, уследить за которыми бывает трудно даже специалисту.
Python развивается с такой скоростью, что всегда есть несколько актуальных версий языка, и выбор версии, актуальной для конкретного применения - частное решение, которое не может быть принято на уровне дистрибутива.
Именно поэтому, python распространющийся в дистрибутивах, как правило, беден пакетами (зачем distribution team лишняя альтернатива?), отстает от апстрима по номерам версий и не хочет (да и не может наверно) решать специфические проблемы python.
Наконец, самое главное, python предлагает свой собственный репозиторий пакетов (PyPI), который по уровню применяемых решений в плане адекватности потребностям языка, существенно обходит то, что есть сейчас в дистрибутивах. Единственный ощутимый недостаток PyPI - отсутствие автоматического поиска зависимостей - является недостатком только с точки зрения единственного в мире дистрибутива, в котором поиск зависимостей _вообще_когда_либо_был_. Ну так, поиск зависимостей - дело поправимое.
Ради чего
Главный выигрыш от использования PyPI вместо системного репозитория - в том, что я могу публиковать свои решения для всего python-комьюнити, а не для его узкого подмножества. Причем, решение становится доступным для моих многоплатформенных коллег в течении 15ти минут.
Конечно есть и свои минусы: стабильность и воспроизводимость результатов, по сравнению со сборкой в hasher под большим вопросом. Но в то же время, на сегодняшний день я напрямую столкнулся с проблемой, которая, боюсь, достаточно общая: сборкой питона и настройкой питоновской сборочной среды занимаются, вообще говоря. невежественнные в плане питона люди. Которые не знают (да и не хотят знать) многие проблемы, известные любому питонисту.
Так что я там говорил про стабильность и воспроизводимость? Да. Работа питона в дистрибутиве воспроизводится лучше. К сожалению, эта работа с каждым днем состоит все больше из багов и крахов. И, видимо, эта проблема более общая чем проблема моего дистрибутива: python-комьюнити и distribution team любого линукс-дистрибутива - это малопересекающиеся множества, и непрофессионально собранные пакеты я вижу везде - от убунты до федоры :), и это мое частное мнение косвенно подтверждается ведущеми разработчиками проектов на питоне, которые говорят: "мы пытались, но ни с одним дистрибутивом не смогли найти взаимопонимания".
Поэтому вот ответ ради чего: ради эффективного взаимодействия с другими участниками python-комьюнити, ради стабильной работы и относительной независимости от непрофессиональных действий участников distribution team.
Руководство по выживанию
Идея выживания на редкость проста: раз уж есть у нас свой репозиторий пакетов PyPI, нужно пользоваться им. Защитники дистрибутивов пугают нас невозможностью сосуществования двух менеджеров пакетов на одном сервере, но ее невозможность сильно преувеличена, и ее легко обойти. На самом деле, существует множество вариантов "разрешенных" условий, при которых два мененджера могут сосуществовать. Приведем один такой вариант, будем называть один менеджер "системным", а второй - "дополнительным";
- Существует перечень пакетов, которые необходимы для корректной работы дополнительного менеджера пакета, если есть договоренность с дистрибъютором - то можно создать системный пакет дополнительного менеджера пакетов, которые требует все пакеты из перечня;
- Никакие системные пакеты не содержат внешних зависимостей, в том числе на пакеты, устанавливаемые дополнительным менеджером пакетов;
- Никакие дополнительные пакеты не содержат зависимостей, которые не могли бы быть разрешены самим дополнительным менеджером пакетов;
- Системный и дополнительный менеджер пакетов устанавливаются таким образом, что конфликты между ними исключены (например, физически в разные места файловой системы).
Я не буду утверждать что этот вариант можно выполнить для любых пакетов, любых языков и любых пакетных менеджеров. Но я утверждаю, что этот вариант легко выполняется для языка python и репозитория PyPI. В самом деле:
- Такой перечень пакетов легко составить, и он достаточно краток. Фактически, это несколько системных библиотек, и, для продвинутых пользователей, компилятор языка С. Кроме того, для полноты картины можно включить в этот перечень сам python, хотя это может быть и не лучшим вариантом;
- Если системные пакеты требуют пакеты, устанавливаемые дополнительным менеджером пакетов, то пусть уважаемые участники Distribution Team сами себе их и соберут. Практика показывает, что соотношение между "системными" питоновскими пакетами и пакетами, требуемыми для нормальной жизни питонисту составляет 1:5, если не 1:20;
- Питон представляет собой, на сегодняшний день, практически замкнутую среду, что косвенно подтверждает возможность установки на разные платформы;
- Разнести системный и дополнительный менеджер пакетов не представляет проблем.
Таким образом, похоже есть шанс :)
Разделение менеджеров пакетов
Дальнейший пример рассматривается для случая дистрибутивов, основанных на sisyphus, но легко адаптируется для других платформ. Физически разделить менеджеры пакетов достаточно просто - будем ставить дополнительные пакеты в /usr/local/, который не затрагивается системным менеджером. Если в вашем случае ситуация иная - просто наберите mkdir и проведите кулаком по клавиатуре: вы нашли ваше изолированное место, которое в дальнейшем можно обозначать как <PREFIX>. Финалом настройки изолированного места будет смена прав и владельцев: создание группы и пользователя python, а так же команда:
chown python:python -R <PREFIX>
позволят вам больше никогда не обращаться к администратору системы.
Настройка дистрибутивного python
Есть два запуска python: для вас, и для всех остальных. Запуск python для вас предполагает, что в PYTHONPATH включено место установки дополнительных пакетов, причем - на первых местах. Итак, в <PREFIX>/bin/python пишем:
#! /bin/bash export PYTHONPATH=<PREFIX>/lib/python2.4/site-packages:$PYTHONPATH /usr/bin/python2.4 $*
Ну а у себя в профайле:
export PATH=<PREFIX>/bin:$PATH
Одну проблему решили: теперь вы пользуетесь своим питоном.
Настройка дистрибутивного setuptool
В настоящий момент я еще не готов послать родной дистрибутив по известному адресу, и все-таки предпочитаю пользоваться системным setuptool, а не собирать его самому. Что бы он ставил пакеты в <PREFIX> при запуске easy_install нужно все время указывать ключик --prefix. Это достает. Решений два:
Обертка на шелле в <PREFIX>/bin/easy_install:
#! /bin/bash /usr/bin/easy_install --prefix=<PREFIX> $*Исправить в системном easy_install строчку:
self.prefix = "/usr"на:
self.prefix = "<PREFIX>"
Я склонен пользоваться вторым, так как в сущности easy_install бесполезен для остального дистрибутива, но об этом лучше договариваться с Distribution Team, если это возможно.
Заключение
Наши эксперименты еще не закончены :), и эта статья, наверно, будет корректироваться. Тем не менее, уже сейчас лично я пробую жить в таком режиме. Это сильно облегчило мои контакты с python community, практически, от того момента, когда пакет готов у меня, до того момента, когда его могут поставить мои соратники проходит не более 10 минут, тогда как даже в лучших дистрибутивах это время измеряется часами, если не годами.
