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

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

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

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

14.2. Трудности разработчиков Python

Иногда выполнение этих условий попросту невозможно. Например, Plone (полнофункциональная система управления содержимым сайта на основе Python) использует сотни небольших библиотек Python, которые не всегда доступны в виде пакетов в существующих системах управления пакетами. Это означает, что система Plone должна быть самодостаточным приложением, в комплект поставки которого включаются все необходимые программные компоненты. Для этого используется система сборки zc.buildout, с помощью которой происходит копирование всех используемых программных компонентов и создание самодостаточного приложения, которое может работать на любой системе в рамках одной директории. На самом деле в итоге получается бинарный релиз, так как любой фрагмент кода на языке C может быть скомпилирован при сборке.

Это является большим подарком для разработчиков: им просто требуется описать зависимости с учетом приведенных ниже стандартов Python и использовать систему сборки zc.buildout для создания релиза приложения. Но, как обсуждалось ранее, данный тип релиза является отделенным от системы, поэтому не устроит большинство администраторов систем на основе Linux. Администраторы Windows-систем не будут против такой системы, но администраторы систем CentOS или Debian будут, так как эти системы выстраивают механизм управления пакетами исходя из предположения о том, что любой файл в системе является зарегистрированным, классифицированным и известным для инструментов администрирования.

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

Простой пример того, как вы можете создать трудности для людей, повторно упаковывающих ваш программный компонент, используя существующую систему управления пакетами Python: можно выпустить библиотеку с названием "MathUtils" версии "Fumanchu". Замечательному математику, разработавшему данную библиотеку, показалось забавным использовать имена своих котов в качестве версий проекта. Но как человек, сопровождающий пакет, узнает о том, что "Fumanchu" является именем второго кота, а первого кота зовут "Phil", поэтому версия "Fumanchu" вышла позднее версии "Phil"?

Может показаться странным, но такая ситуация вполне вероятна при использовании современных инструментов и стандартов. Плохо еще и то, что такие инструменты, как easy_install и pip используют нестандартные системы для отслеживания установленных файлов и сортируют версии "Fumanchu" и "Phil" в алфавитном порядке.

Другой проблемой является метод работы с файлами данных. Например, что будет, если ваше приложение использует базу данных SQLite? Если вы поместите базу данных в директорию вашего пакета, ваше приложение может работать некорректно, так как операционная система запрещает осуществлять запись в файлы, расположенные в данной части дерева файловой системы. Данный подход также нарушает предположения разработчиков операционных систем на основе ядра Linux о том, где должны находиться резервные копии данных приложений (в директории /var).

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

Далее: 14.3 Современная архитектура системы управления пакетами