Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

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

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

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

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

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

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

14.4.1. Метаданные

Первым шагом является усовершенствование стандарта метаданных. Стандарт PEP 345 описывает новую версию формата метаданных, которая предусматривает:
  • более корректный метод указания версий
  • зависимости уровня проекта
  • стандартный метод для описания зависимых от платформы значений

Версия

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

Единственной возможностью установления постоянного формата версий является публикация стандарта, которому будут следовать проекты. Выбранная нами схема является классической схемой на основе последовательности версий. Как описано в стандарте PEP 386, для указания версий используется следующий формат строки: 
N.N[.N]+[{a|b|c|rc}N[.N]+][.postN][.devN]
где:
  • N является целочисленным значением. Вы можете использовать столько значений N, сколько хотите, при этом следует учитывать, что значения должны быть разделены точками и их должно быть не менее двух (ВЕРСИЯ.ПОДВЕРСИЯ).
  • a,b,c и rc являются обозначениями alpha-версии, beta-версии и кандидата в релизы. После них следует целочисленное значение. Для кандидатов в релизы используются два последних обозначения, так как мы хотели сделать схему совместимой со схемой Python, в которой используется rc. При этом нам кажется, что использовать c проще.
  • dev с последующим целочисленным значением является обозначением версии для разработчиков.
  • post с последующим целочисленным значением является обозначением версии, выпущенной после релиза.

В зависимости от процесса разработки, обозначения dev и post могут использоваться для всех промежуточных версий, выпускаемых между двумя финальными релизами. Для большей части релизов в процессе разработки используется обозначение dev.

Используя эту схему, стандарт PEP 386 определяет строгую последовательность:
  • alpha-версия < beta-версия < кандидат в релизы < финальный релиз
  • версия для разработчиков < обычная версия < версия, выпущенная после релиза, где обычной версией может быть alpha-версия, beta-версия, кандидат в релизы или финальная версия
Ниже приведен пример указания версий: 
1.0a1 < 1.0a2.dev456 < 1.0a2 < 1.0a2.1.dev456
  < 1.0a2.1 < 1.0b1.dev456 < 1.0b2 < 1.0b2.post345
    < 1.0c1.dev456 < 1.0c1 < 1.0.dev456 < 1.0
      < 1.0.post456.dev34 < 1.0.post456

Целью разработки этой схемы было простое преобразование версий пакетов Python в версии для других систем управления пакетами. В данный момент каталог PyPI отклоняет любые загружаемые проекты, использующие стандарт PEP 345 для метаданных с версией, не соответствующей стандарту PEP 386.

Зависимости

Стандарт PEP 345 описывает три новых поля, заменяющих поля из стандарта PEP 314 Requires, Provides и Obsoletes. Этими полями являются Requires-Dist, Provides-Dist и Obsoletes-Dist, которые могут использоваться по нескольку раз в метаданных.

Каждая строка поля Requires-Dist должна содержать название другого проекта в формате Distutils, требуемого для работы данного проекта. Формат строки идентичен формату названия проекта в Distutils (т.е. формату, используемому при объявлении названия проекта в поле Name), после которого в скобках может следовать объявление версии. Эти названия проектов в формате Distutils должны соответствовать названиям проектов, используемым в PyPI, а объявления версий - соответствовать стандарту PEP 386. Некоторые примеры приведены ниже: 
Requires-Dist: pkginfo
Requires-Dist: PasteDeploy
Requires-Dist: zope.interface (>3.5.0)
Поле Provides-Dist используется для указания дополнительных названий проектов в рамках данного проекта. Оно полезно в том случае, когда несколько проектов объединяются. Например, проект ZODB может включать в свой состав проект transaction и использовать следующее объявление: 
Provides-Dist: transaction
Поле Obsoletes-Dist полезно в том случае, когда необходимо указать на то, что версия другого проекта становится устаревшей после установки проекта: 
Obsoletes-Dist: OldName

Маркеры окружения

Маркер окружения является условным переходом, зависящим от окружения исполнения и добавляемым в конец поля после точки с запятой. Некоторые примеры приведены ниже: 
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Obsoletes-Dist: pywin31; sys.platform == 'win32'
Requires-Dist: foo (1,!=1.3); platform.machine == 'i386'
Requires-Dist: bar; python_version == '2.4' or python_version == '2.5'
Requires-External: libxslt; 'linux' in sys.platform
Микроязык для маркеров окружения сознательно разработан с учетом простоты понимания разработчиками, не знакомыми с языком Python: он сравнивает строки с помощью операторов == и in (и противоположных) и позволяет использовать обычные логические комбинации. Поля из стандарта PEP 345, совместно с которыми могут использоваться эти маркеры:
  • Requires-Python
  • Requires-External
  • Requires-Dist
  • Provides-Dist
  • Obsoletes-Dist
  • Classifier

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