Куда пропала Python Policy
2007-11-13 20:07В статье рассказывается история рождения и смерти Python Policy. И говорится несколько слов о том, что будет с ней дальше. Если, конечно, ей имеет смысл быть дальше...
Куда пропала Python Policy (PyPO)?
Python Policy - это было изобретение некоторого (небольшого) сообщества людей, основной движущей силой которых было желание обеспечить простоту и эффективность пакетирования больших проектов на питоне. В общем (с большим или меньшим успехом) все возникающие при этом проблемы были решены. Мы с удовольствием использовали и сами правила, которые изобрели, и некоторое количество программного обеспечения, которое мы разработали что бы поддержать это полиси.
Фактически, на упаковку небольшого пакета, взятого из репозитория разработчиков, могло уйти не более 10-15ти минут.
К сожалению, PyPO подразумевала, что пакеты собирают профессионалы-питонисты, которых в дистрибутиве оказалось удручающе мало. Те случайные люди, которые зачем-то собирали достаточно нетривиальные питоновские пакеты, не использовали и половины имеющихся возможностей, а потому элементарно не могли решить проблемы, которые иногда возникали при сборке.
В обстановке не прекращающейся травли, PyPO Team естественным образом распалась: я лег в больницу на несколько лет, хотя всякий интерес к мантейнерству потерял еще задолго до этого. Остальные разработчики так же были отторгнуты социумом Alt Linux Team и разработка PyPO на долгое время оказалась в состоянии стагнации. Выходили новые версии питона, обнаруживались новые ошибки, а полиси кое-как себе работала.
В настоящее время, сотрудники компании AltLinux, вопреки мнению части python-разработчиков, которые еще остались в дистрибутиве, двинулись новым курсом, который сводится к следующим двум предположениям:
1.Python Policy слишком сложна и решает проблемы, которые не существуют в реальной жизни, а потому должна быть подвергнута максимально возможной редукции;
2.Основное требование к механизмам сборки и анализа зависимостей - это собираемость дистрибутива, даже вопреки его возможной неработоспособности.
Любые замечания на эту тему полностью игнорируются, или воспринимаются как попытка отстоять свое (заведомо неправильное) мнение. Честно говоря я не знаю кто тут прав, а кто виноват, но предпочитаю отойти в сторонку.
Бранч
Однако большая часть тематики PyPO осталась интересна лично мне. Это в первую очередь поиск и обнаружение зависимостей, во вторую - анализ _кода_ на актуальность этих зависимостей, в третью - на принятие решений относительно пакетирования или изменения расположения кода между пакетами основываясь на графе этих зависимостей.
Бранч на эту тему был сделан давно, еще когда PyPO была в наших руках. В результате даже образовалось два комплекта кода, для поиска зависимостей - старый и новый, причем новый был сильно подрезан в возможностях, так что бы сконцентрироваться на основных функциях (собственно анализе кода). Все это лежало без движения три года (потеря интереса к жизни), сейчас я поднял этот код и начал потихоньку искать где и как его с пользой применить.
Жизнь без APT
Я не собираюсь менять дистрибутив, Но, дистрибутивным питоном и дистрибутивным репозиторием пакетов скоро, видимо, станет пользоваться небезопасно. Однако жизнь несет альтернативы: setuptools, zc.buildout, PyPI постепенно дорастают до возможностей и потребностей реального мира. Мы даже располагаем пакеты в PyPI, что существенно быстрее и проще чем работа с репозиторием sisyphus (не подумайте что это упрек, равных sisyphus'у все равно нет). Единственная серьезная проблема - никто другой еще не дорос до поиска зависимостей так, как AltLinux. Но меня это не пугает: моя искалка зависимостей будет востребована, сейчас она на скорую руку собрана pd.requires и лежит в PyPI, что неплохо решает проблему "первой пробы".
Сейчас моя альтернатива - это оставаясь в пределах AltLinux ставить python и всё с ним связанное мимо него, ориентируясь на easy_install. PyPI и тому подобные инструменты. Пока что я изучаю вопрос и пользуюсь. Что будет дальше - жизнь покажет.
Рефакторинг пакета
Унаследованный от PyPO инструмент придется изменить. В отдельный пакет выносится искалка зависимостей, в отдельный пакет - различные инструменты их анализа.
Искалка зависимостей
Для искалки зависимостей будет введен специальный API, позволяющий получать зависимости откуда угодно, причем зависимости в исходном коде, тем более питона, это частный и совсем не важный случай. Зависимости могут быть:
- Между пакетами rpm;
- Между подписчиками на конференцию;
- Между статьями на сайте;
- Между авторами книг в библиотеке;
- Между работниками в компании.
В любом случае, искалка зависимостей должна выдавать описание в стандартной форме, возможно в той, которая сейчас принята для RPM, а может и более сложной.
Аналитика
Аналитическая часть пакета призвана отвечать на вопросы, связанные с зависимостями между "сущностями":
- Является ли система зависимостей замкнутой;
2. Как можно эффективно разбить сущности на группы (например, питоновские модули на пакеты).
3. Какие зависимости являются "странными" (ну, например, могут подозреваться как ложные).
Множество таких вопросов встает при разработке ПО и решении ряда других задач. Те задачи, которые возникали в дистрибутиве, просто меркнут перед ними.
План
1.Понятное дело, сделать более менее работающую искалку зависимостей, это пакет pd.requires, который более-менее работает уже.
2.Выкинуть оттуда альтовские артефакты. Это уже делается, но, увы, немного медленно.
3.Разбить пакет на два пакета: pd.requires и pd.imalyzer, в первый войдет поиск зависимостей, поставляющий их в стандартной форме, во второй - аналитические инструменты.
Сама попытка сделать это уже была: пакет разбит на две независимых части, но вот единого интерфейса между ними не существует.
Заключение
Нетрудно видеть, что этот пакет имеет шансы пожить. Правда, вряд ли имеет шансы опять попасть в AltLinux, так как его развитие, так же как и их деградация, приводят к потере точек соприкосновения. Предположительно, части завершенного проекта уже не смогут быть использованы именно для поиска зависимостей в AltLinux. Так как цель, которая ставится, существенно более серьезна, а подавляющее большинство Core AltLinux Team серьезные проблемы решать не хочет и не умеет даже при наличии готовых решений.
