Рефакторинг конфигурации модуля Python, чтобы избежать относительного импорта
Это связано с моим предыдущий вопрос.
Я понимаю, как хранить и читать файлы конфигурации. Есть варианты, такие как ConfigParser и ConfigObj.
Рассмотрим эту структуру для гипотетического модуля «яйца»:
eggs/
common/
__init__.py
config.py
foo/
__init__.py
a.py
"egg.foo.a" нужна некоторая конфигурационная информация. То, что я сейчас делаю, это в "а",
import eggs.common.config. One problem with this is that if 'a' is moved to a deeper level in the module tree, the relative imports break. Absolute imports don't, but they require your module to be on your PYTHONPATH.
Возможной альтернативой вышеуказанному абсолютному импорту является относительный импорт. Таким образом, в 'а'
import .common.config
Не обсуждая достоинства относительного и абсолютного импорта, я задавался вопросом о других возможных решениях?
edit - Удален контекст VCS
Ответы 5
Требовать оператора от pkg_resources может быть то, что вам нужно.
Как я понял из этого и предыдущих вопросов, вам нужен только один путь в sys.path. Если мы говорим о git как о VCS (упомянутом в предыдущем вопросе), когда только одна ветка извлекается в любое время (один рабочий каталог). Вы можете переключать и объединять ветки так часто, как захотите.
Я удалил контекст VCS, поскольку понял, что он не имеет отношения к моему вопросу. Переключение VCS только что поставило передо мной этот конкретный вопрос дизайна.
Я думаю о чем-то вроде решения, основанного на выталкивании. Вместо того, чтобы импортировать общие объекты (будь то для конфигурации или каких-либо служебных функций), пусть в этом верхнего уровня экспортирует их, а каждый промежуточный в этом импортирует их из уровня выше и немедленно повторно экспортирует.
Я не уверен, правильно ли я понял терминологию Python, поправьте меня, если я ошибаюсь.
Таким образом, любой модуль, которому необходимо использовать общий объект (который в контексте этого примера представляет информацию о конфигурации), просто импортирует его из в этом на своем собственном уровне.
Это звучит разумно / выполнимо?
"импорт ... требует, чтобы ваш модуль был на вашем PYTHONPATH"
Верно.
Итак, что не так с настройкой PYTHONPATH?
Если у вас одновременно разрабатывается несколько наборов файлов (например, несколько веток), будет сложнее переключаться с одного на другой, если вам нужно каждый раз менять PYTHONPATH; Кроме того, он добавляет зависимость, требующую некоторой работы, чтобы перейти под контроль версий.
Вы можете обмануть механизм импорта, добавив каждый подкаталог в egg/__init__.py:
__path__.append(__path__[0]+"\\common")
__path__.append(__path__[0]+"\\foo")
затем вы просто импортируете все модули из пространства имен egg; например import egg.bar (при условии, что у вас есть файл egg / foo / bar.py) .
Обратите внимание, что foo и common не должны быть пакетом - другими словами, они не должны содержать файл __init__.py.
Это решение полностью решает проблему перемещения файлов; однако он сглаживает пространство имен и, следовательно, может быть не таким хорошим, особенно в больших проектах - лично я предпочитаю полное разрешение имен.
Связанный вопрос: stackoverflow.com/questions/171785/…