Как передавать имя приложения в setup.py?

Question

[Антон Хромов]

Всем доброго времени суток!

Есть приложение на python 3, где имя приложения (далее app_name) используется в нескольких модулях. Для удобства было решено определить app_name один раз в модуле misc и импортировать его оттуда там, где это необходимо.
При сборке дистрибутива с помощью setuptools, была выявлена следующая проблемка: в файле setup.py импортирование app_name из misc потянуло за собой импортирование всего, что содержится в __init__. А это не есть хорошо. Уточню, что в misc нет импортирования чего-либо, только объявление нескольких переменных.

Решение, которое нашлось здесь:
https://python-packaging-user-guide.readthedocs.io...

заключается в использовании exec() для парсинга файла misc.py. Что и было использовано. Так вот, вопрос в том, является ли это лучшим решением и почему производится импортирование из __init__.py? Буду рад ознакомиться с вашими мыслями.

Answer 1

[qlkvg]

А, собственно, в чем проблема? Если в __init__.py нет ничего криминального, то пусть app_name там и лежит. Ну импортнется по ходу сборки несколько модулей/переменных, что в этом страшного? Главное чтобы никакой логики там не было, которая не даст sdist (bdist, bdist_wheel etc.) нормально отработать.
edited: Прочитал внимательнее. Покажите структуру проекта и как импорт модуля misc происходит.

Comments

[Антон Хромов]

Ну, во-первых, предположим что нам может потребоваться собирать пакет из разных окружений. Получается, что для сборки нам нужно поставить все библиотеки, которые импортируются в __init__? А если таких пакетов 10 и в каждом есть зависимости? Может я чего-то не понимаю, но по-моему, это не pythonic way)

[qlkvg]

Поправил ответ. Вариант с exec вполне нормальный. Вообще подходов и к хранению версии, и к наполнению __init__.py у всех разный. Я наоборот предпочитаю держат в ините только служебную информацию (ту же версию) и не делатьв нем никаких импортов. https://packaging.python.org/single_source_version... - вот тут несколько подходов описано, в том числе и через exec.

[Антон Хромов]

Структура проекта у меня схожая с использованной в yapf:
https://github.com/google/yapf/tree/master/yapf

За ссылку спасибо, но я ту же самую в вопросе прикрепил :)

[qlkvg]

Черт. Надо больше спать=)

[qlkvg]

А misc по относительному или абсолютному пути импортируете?

[Антон Хромов]

Он у меня лежит в пакете request_sync, соответственно в setup.py это выглядит так:

import request_sync.misc

[qlkvg]

Ну если выполняется __init__.py из пакета request_sync, то это обычное поведение питона. Если __init__.py из вышестоящего пакета, значит где-то есть перекрестный импорт. Вот примерно поэтому я не люблю ничего держать в __init__.py)

[Антон Хромов]

Да, в request_sync... То есть правильно ли я понял, что когда мы что-либо импортируем из модуля, находящегося в пакете, то всегда будет импортироваться __init__ этого пакета?

[qlkvg]

Насколько я понимаю, да. Можно нахачить что-то вроде sys.path.append("./request_sync"), и импортировать misc уже напрямую, но имхо это куда менее элегантное решение, чем уже существующее.

[Антон Хромов]

Ага, это уже знатный костыль) Ладно, спасибо за обсуждение. Вроде разобрался теперь, как это работает.