Лучший способ импортировать модули из других папок в python
Мой текущий способ импорта написанных мной скриптов выглядит так:
import sys
sys.path.append('../../')
from lib.helper import file_manager
потому что моя структура папок выглядит так:
|
├── lib
│ ├── upm
│ └── helper
| └── file_manager.py <- the imported file.
│
└── src
└── deployment
└── cli.py <- the executed file.
Поэтому, когда cli.py запускается, он должен добавить корневую папку на sys.path, прежде чем он сможет включать что-либо из lib. Если я перемещаю cli.py, мне придется изменить эту строку, чтобы отразить, насколько он вложен: sys.path.append('../../')
Должен быть лучший способ импортировать модули, которые находятся в одном проекте. Из-за этого плохого паттерна я слишком много борюсь с текущим рабочим каталогом моего проекта.
Что бы вы сделали на моем месте?
В идеале нужно развернуть с помощью setup.py / pip install ., а не просто копировать дерево исходных текстов. Затем, предполагая, что вы правильно поняли все, что связано с setuptools, вы получите свои библиотеки в пакетах сайтов и сценарии в виде сценариев, которые просто используют библиотеки из пакетов сайта, и все это просто работает.
Я попытался использовать в этом.py в моем случае и потерпел неудачу. В итоге я использовал sys.path.insert (0, '../pathhere/'). Я тоже ищу лучшее решение;)
@abarnert Я склоняюсь к этому подходу, проблема в том, что я делаю автоматизированные контейнеры докеров, поэтому мне придется установить pip install . с файлом python, что означает, что файл python, отвечающий за установку этих зависимостей, по-прежнему имеет эту проблему. .. так что я надеялся, что есть альтернативное «идеальное решение»
@LegitStack В этом случае вы можете pip install в переносимой виртуальной среде, а затем развернуть всю эту среду в контейнере докера. (Таким образом вы также гарантируете, что в контейнере есть правильные сторонние библиотеки и т. д., Без необходимости добавлять их все в свое дерево исходных текстов.)
@abarnert, возможно, это лучший способ - мы относились к самому контейнеру докера как к виртуальной среде, но пока у нас есть процесс, посредством которого мы обновляем докер последней виртуальной средой (поскольку мы много меняем в dev), я думаю это было бы лучшей практикой. Благодарность
@LegitStack Я работал над проектами, которые делали это в обоих направлениях, и если вы можете использовать переносимый env (потому что все ваши блоки разработчика, настройка и контейнеры CI совместимы - что в основном означает обеспечение того, чтобы любые модули расширения поступали с колес manylinux), это намного проще. (Если вы не можете этого сделать, вы все равно можете написать сценарий env-builder, который будет использоваться при создании контейнера, а также при настройке CI и dev, но это дополнительная работа, которая также делает обновление пакетов более болезненным.)
Вы можете использовать python setup.py develop, если проблема связана с pip (я также предлагаю использовать pip install -e ., если вы используете pip).
вы можете добавить lib в свой путь к python? Затем управляйте file_manager с помощью файла в этом.py в папке upm, чтобы вы могли выполнять импорт из upm.helper import file_manager