PYTHONPATH по сравнению с sys.path
Другой разработчик и я не соглашаемся об или PYTHONPATH, или sys.path должен использоваться, чтобы позволить Python находить пакет Python в пользователе (например, разработка) каталогом.
У нас есть проект Python с типичной структурой каталогов:
Project
setup.py
package
__init__.py
lib.py
script.py
В script.py мы должны сделать import package.lib. Когда пакет установлен в пакетах сайта, script.py может найти package.lib.
При работе из пользовательского каталога, однако, что-то еще должно быть сделано. Мое решение состоит в том, чтобы установить мой PYTHONPATH для включения "~ / Проект". Другой разработчик хочет поместить эту строку кода в начале script.py:
sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
Так, чтобы Python мог найти локальную копию package.lib.
Я думаю, что это - плохая идея, поскольку эта строка только полезна для разработчиков или людей, работающих из локальной копии, но я не могу привести серьезную причину, почему это - плохая идея.
Мы должны использовать PYTOHNPATH, sys.path, или любой в порядке?
5 ответов
Если единственная причина для изменения пути - это разработчики, работающие из своего рабочего дерева, то вам следует использовать инструмент установки, чтобы настроить вашу среду за вас. virtualenv очень популярен, и если вы используете setuptools, вы можете просто запустить setup.py develop , чтобы частично установить рабочее дерево в вашей текущей установке Python.
I hate PYTHONPATH. I find it brittle and annoying to set on a per-user basis (especially for daemon users) and keep track of as project folders move around. I would much rather set sys.path in the invoke scripts for standalone projects.
However sys.path.append isn't the way to do it. You can easily get duplicates, and it doesn't sort out .pth files. Better (and more readable): site.addsitedir.
And script.py wouldn't normally be the more appropriate place to do it, as it's inside the package you want to make available on the path. Library modules should certainly not be touching sys.path themselves. Instead, you'd normally have a hashbanged-script outside the package that you use to instantiate and run the app, and it's in this trivial wrapper script you'd put deployment details like sys.path-frobbing.
В общем, я бы подумал о настройке переменной среды (например, PYTHONPATH)
быть плохой практикой. Хотя это может быть хорошо для разовой отладки, но используется как
регулярная практика может быть не очень хорошей идеей.
Использование переменной окружения приводит к ситуациям типа «у меня работает», когда кто-то
else сообщает о проблемах в базе кода. Также можно провести ту же практику с
тестовой среде, что приводит к ситуациям, подобным тем, что тесты работают нормально для
конкретного разработчика, но, вероятно, терпит неудачу, когда кто-то запускает тесты.
Наряду со многими другими уже упомянутыми причинами, вы также можете указать на жесткое кодирование
sys.path.append (os.path.dirname (os.path.dirname (os.path.abspath (__ file __)))
хрупкий, потому что предполагает расположение script.py - он будет работать, только если script.py находится в Project / package. Он сломается, если пользователь решит переместить / скопировать / символическую ссылку script.py (почти) куда-нибудь еще.
I think, that in this case using PYTHONPATH is a better thing, mostly because it doesn't introduce (questionable) unneccessary code.
After all, if you think of it, your user doesn't need that sys.path thing, because your package will get installed into site-packages, because you will be using a packaging system.
If the user chooses to run from a "local copy", as you call it, then I've observed, that the usual practice is to state, that the package needs to be added to PYTHONPATH manually, if used outside the site-packages.