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

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

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

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

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

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

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

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

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

Использование файлов данных

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

import os

here = os.path.dirname(__file__)
cfg = open(os.path.join(here, 'config', 'mopy.cfg'))

Подразумевается, что конфигурационные файлы устанавливаются аналогично файлам с кодом и разработчик обязан разместить эти файлы вместе с кодом: в этом примере в поддиректории с именем config.

Новые архитектурные решения в отношении работы с файлами данных позволяют использовать дерево директорий проекта в качестве корневой директории для всех файлов, а также позволяют получать доступ к любому файлу в этом дереве независимо от того, расположен ли он в пакете Pyhon или в простой директории. Эти решения позволили разработчикам создавать отдельную директорию для файлов данных и получать доступ к ним с помощью метода pkgutil.open:

import os
import pkgutil

# Открыть файл, расположенный в директории config/mopy.cfg проекта MPTools
cfg = pkgutil.open('MPTools', 'config/mopy.cfg')

Метод pkgutil.open получает доступ к метаданным проекта и проверяет наличие файла RESOURCES. В этом файле находится простой список соответствия для имен файлов и возможных мест их расположения в системе:

config/mopy.cfg {confdir}/{distribution.name}

В данном случае переменная {confdir} указывает на системную директорию для файлов конфигурации, а переменная {distribution.name} содержит имя проекта Python, извлеченное из метаданных.

Рисунок 14.4: Поиск файла

Как только данный файл метаданных RESOURCES создается во время установки, у разработчика появляется возможность с помощью API узнать о расположении файла mopy.cfg. И так как путь config/mopy.cfg относится к дереву директорий проекта, появляется возможность для реализации режима разработчика, в котором метаданные для проекта генерируются в директории проекта и путь к ним добавляется в список директорий поиска pkgutil.

Объявление файлов данных

На практике проект может установить место расположения файлов данных, объявив сопоставление в файле setup.cfg. Сопоставление является списком кортежей формата (шаблон в формате glob, целевой путь). Каждый шаблон соответствует одному или нескольким файлам в дереве проекта, а целевой путь указывает путь для установки и может содержать переменные в фигурных скобках. Например, файл setup.cfg проекта MPTools может выглядеть подобным образом:

[files]
resources =
        config/mopy.cfg {confdir}/{application.name}/
        images/*.jpg    {datadir}/{application.name}/

В модуле sysconfig объявлен и документирован список специальных переменных, которые могут быть использованы, а также их значения по умолчанию для каждой из платформ. Например, значением переменной {confdir} является строка /etc в Linux. Таким образом, установщики могут использовать это сопоставление вместе с модулем sysconfig во время установки для получения путей для копирования файлов. В конечном счете, установщики будут генерировать упоминавшийся ранее файл RESOURCES в составе метаданных и, таким образом, расположение этих файлов сможет быть установлено впоследствии с помощью функций модуля pkgutil.

Рисунок 14.5: Установщик

Далее: 14.4.4. Усовершенствования каталога PyPI