Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

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

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

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

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


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

Большинство разработчиков Python желают, чтобы их программы были работоспособны в любом программном окружении. Также обычно они предпочитают использовать комбинацию стандартных библиотек языка Python и системно-зависимых библиотек. Но пока вы не создаете отдельные пакеты для каждой из систем управления пакетами, вам приходится создавать релизы для Python - эти релизы создаются для установки с помощью соответствующей системы из состава 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 Современная архитектура системы управления пакетами


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют