Архитектура системы управления пакетами в Python

Глава 14 из 1 тома книги "Архитектура приложений с открытым исходным кодом".

Оригинал: Python Packaging
Автор: Tarek Ziade
Дата публикации: 7 Июня 2012 г.
Перевод: А.Панин
Дата публикации перевода: 3 апреля 2013 г.

Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

14.4. Усовершенствованные стандарты

14.4.2. Что установлено?

Использование единого формата списков установленных файлов для всех инструментов Python необходимо для их взаимодействия. Если мы хотим, чтобы установщик A определял то, что установщик B установил ранее проект Foo, оба этих установщика должны использовать и обновлять одну и ту же базу данных установленных проектов.

Конечно же, в идеальном случае пользователи должны использовать один установщик в их системе, но им может понадобиться перейти к использованию нового установщика, предоставляющего специфические возможности. Например, в составе Mac OS X поставляется пакет Setuptools, поэтому пользователи автоматически получают в свое распоряжение сценарий easy_install. Если они пожелают перейти к использованию нового инструмента, им придется воспользоваться инструментом, который поддерживает обратную совместимость с предыдущим.

Другой проблемой является использование установщика Python на платформах, использующих системы управления пакетами, аналогичные RPM, так как в этом случае нет способа информировать систему об установке проекта. Вся сложность заключается в том, что хотя система управления пакетами Python и может каким-либо образом получить доступ к центральной системе управления пакетами, возникнет необходимость сопоставления метаданных Python с метаданными центральной системы управления пакетами. Название проекта, например, может быть различным для этих систем. Это может произойти по нескольким причинам. Наиболее известной причиной является конфликт названий: другой проект вне экосистемы Python может использовать то же название в рамках системы управления пакетами RPM. Другой причиной является использование префикса python, которое нарушает соглашение, используемое при создании пакетов для платформы. Например, если название вашего проекта foo-python, велика вероятность, что пакет RPM в системе Fedora будет назван python-foo.

Одним из способов преодоления данной проблемы является глобальная установка Python с помощью центральной системы управления пакетами и работа в изолированном окружении. Такие инструменты, как Virtualenv могут помочь в этом случае.

В любом случае нам необходим единый формат установки пакетов в Python, так как другим системам установки пакетов также необходимо взаимодействовать с системой установки пакетов Python в тех случаях, когда пакеты Python устанавливаются с помощью них. Как только сторонняя система управления пакетами регистрирует установленный проект в своей базе данных, ей необходимо сгенерировать корректные метаданные установки для Python таким образом, чтобы проекты определялись как установленные установщиками Python и другими API, запрашивающими данные об установленных пакетах в Python.

Сопоставление метаданных актуально и в данном случае: так как система управления пакетами RPM обладает информацией о том, какие проекты Python устанавливаются с помощью нее, она может генерировать корректные метаданные уровня Python. Например, данной системе известно, что названию python26-webob соответствует название WebOb в экосистеме PyPI.

Как только все существующие инструменты будут поддерживать этот формат, у нас будет возможность управлять проектами Python вне зависимости от определенного установщика и его возможностей. Также, поскольку стандарт PEP 376 описывает хранилище метаданных в виде директории, расширение метаданных сводится к добавлению новых файлов. На самом деле, новый файл метаданных с именем RESOURCES, описанный в следующем разделе, может быть добавлен в ближайшем будущем без внесения изменений в стандарт PEP 376. В конечном счете, если этот новый файл окажется полезным для всех инструментов, его описание будет добавлено в стандарт PEP.

Далее: 14.4.3. Архитектурные решения в отношении работы с файлами данных