Организация нескольких приложений Python и пакетов общих библиотек

1

Предположим, что я пишу два приложения для своего работодателя, мы будем называть их App1 и App2. Эти приложения зависят от некоторых пакетов, содержащих код, необходимый для обоих. Скажем, что App1 зависит от PackageA и PackageB. App2 зависит от PackageB и PackageC. Стратегия организации, которая кажется мне естественной, - проверить все на контроль версий следующим образом:

repo_root
+--- App1
|    +--- App1.py
|    +--- ... and so on
+--- App2
|    +--- ... files for App2
+--- PackageA
|    +--- __init__.py
|    +--- ... and more files
+--- PackageB
|    +--- ... files for PackageB
+--- PackageC
     +--- ... files for PackageC

Проблема связана с импортом пакетов. Например, App1 и App2 необходимо импортировать PackageB, но я не могу просто поставить "import PackageB" в основной файл для каждого этих приложений. Python не ищет родительский каталог для импортируемых пакетов.

Я знаю пару вариантов для этого, но они оба кажутся немного уродливыми. Одна из стратегий, которую я использовал ранее, - это разместить основной файл для App1 и App2 в каталоге "repo_root". Тогда два основных файла могут импортировать пакеты без каких-либо проблем. Другой вариант - использовать sys.path.append и файл, чтобы выяснить, что представляет собой родительский каталог, и добавить его в путь, который Python ищет для модулей.

Есть ли чистый, элегантный способ сделать что-то подобное? Благодарим за помощь.

Обновление: В то время как решение virtualenv может очень помочь в решении проблем с пакетами и зависимостями, это почти похоже на излишнюю проблему, которая может быть решена путем относительного импорта. Однако перенос относительного импорта кажется дьявольски сложным. Существует PEP 366, но это довольно сложно и, вероятно, не позволит импортировать за пределы пакета. Я потратил некоторое время на importlib, но я уверен, что не разрешает импорт за пределы пакета. Многие люди, похоже, используют munging sys.path, из которых этот кажется лучшим примером, который я нашел. Но, как я уже упоминал, это выглядит довольно хакерским способом. Я потратил почти весь день на расследование этого, и я не думаю, что есть ответ. Исправьте меня, если я ошибаюсь, но теперь я полагаю, что нет чистого, не-хакерского способа сделать относительный импорт, не принося тяжелого нападающего, такого как virtualenv и некоторые .pth файлы. Во всяком случае, еще раз спасибо за вашу помощь. Я отмечу это как ответ, так как virtualenv - единственный вариант.

Теги:
packages

2 ответа

3
Лучший ответ

Одним из решений, которое вы можете использовать для этого, является virtualenv для каждого из ваших приложений, а затем используйте относительный .pth файл, чтобы указать на Пакеты. Это дает вам прекрасный контроль над средой, в которой каждый из приложений разрабатывается и избегает "но у меня есть пакет_x на моей машине!". проблемы при тестировании.

  • 0
    Я читал и смотрел некоторые скринкасты, и я думаю, что понял. Я могу создать скрипт начальной загрузки virtualenv для App1 и App2, который установит необходимые библиотеки с открытым исходным кодом, а также файл .pth (который должен быть помещен в папку типа «site-packages»). После проверки запуск начальной загрузки создаст среду, позволяющую запустить приложение. Для развертывания я мог бы использовать тот же загрузчик для настройки производственного сервера? Это правильно?
  • 0
    Довольно много. Большим преимуществом разработки в virtualenv является точное знание требований к развертыванию, и развертывание в virtualenv - это определенно вариант, который следует рассмотреть.
1

virtualenv - это чистый и элегантный способ решения таких проблем. Прочтите праймер, затем резюме pypi, затем установите его и попробуйте!

Ещё вопросы

Сообщество Overcoder
Наверх
Меню