PYTHONPATH противсистемный путь

Question

Другой разработчик и я расходимся во мнениях о том, следует ли использовать PYTHONPATH или sys.path, чтобы позволить Python находить пакет Python в пользовательском каталоге (например, development).

У нас есть проект на Python с типичной структурой каталогов:

Project
    setup.py
    package
        __init__.py
        lib.py
        script.py

В script.py нам нужно сделать import package.lib.Когда пакет установлен в site-packages, script.py можно найти package.lib.

Однако при работе из каталога пользователя необходимо выполнить что-то еще.Мое решение состоит в том, чтобы установить в моем PYTHONPATH значение "~/Project".Другой разработчик хочет поместить эту строку кода в начало script.py:

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

Чтобы Python мог найти локальную копию package.lib.

Я думаю, что это плохая идея, поскольку эта строка полезна только для разработчиков или людей, работающих с локальной копией, но я не могу привести вескую причину, почему это плохая идея.

Должны ли мы использовать PYTOHNPATH, sys.path, или и то, и другое нормально?

Answer 1

Если единственная причина для изменения пути заключается в том, что разработчики работают из своего рабочего дерева, то вам следует использовать средство установки для настройки вашей среды под себя.virtualenv очень популярен, и если вы используете setuptools, вы можете просто запустить setup.py develop чтобы частично установить рабочее дерево в вашей текущей установке Python.

Answer 2

Я ненавижу PYTHONPATH.Я нахожу хрупким и раздражающим настраивать для каждого пользователя (особенно для пользователей daemon) и отслеживать перемещение папок проекта.Я бы гораздо предпочел установить sys.path в сценариях вызова для автономных проектов.

Однако sys.path.append это не тот способ, которым нужно это делать.Вы можете легко получить дубликаты, и это не приведет к сортировке .pth Файлы.Лучше (и более читабельно): site.addsitedir.

И script.py обычно это не было бы более подходящим местом для этого, поскольку это внутри пакет, который вы хотите сделать доступным по пути.Библиотечные модули, безусловно, не должны соприкасаться sys.path сами по себе.Вместо этого у вас обычно есть hashbanged-script вне пакета, который вы используете для создания экземпляра и запуска приложения, и именно в этот тривиальный сценарий-оболочку вы помещаете детали развертывания, такие как sys.path-фроббинг.

Answer 3

В общем, я бы счел настройку переменной окружения (например, PYTHONPATH) плохой практикой.Хотя это могло бы быть прекрасно для одноразовой отладки, но используя это как
регулярная практика может оказаться не очень хорошей идеей.

Использование переменной окружения приводит к ситуациям типа "у меня это работает", когда кто-то
else сообщает о проблемах в базе кода.Также можно было бы применить ту же практику и к тестовой среде, что приводит к таким ситуациям, как тесты, выполняющиеся нормально для конкретного разработчика, но, вероятно, терпящие неудачу, когда кто-то запускает тесты.

Answer 4

Наряду со многими другими причинами, упомянутыми ранее, вы также могли бы указать на то, что жесткое кодирование

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

хрупкий, потому что он предполагает местоположение script.py - это будет работать, только если script.py находится в Project / package .Он сломается, если пользователь решит переместить / скопировать / символическую ссылку script.py (почти) в другое место.

Answer 5

Я думаю, что в этом случае использование PYTHONPATH лучше, главным образом потому, что оно не вводит (сомнительный) ненужный код.

В конце концов, если вы подумаете об этом, ваш пользователь ему это не нужно sys.path дело в том, что ваш пакет будет установлен в site-packages, потому что вы будете использовать систему упаковки.

Если пользователь выбирает запуск из "локальной копии", как вы это называете, то я заметил, что обычной практикой является указание, что пакет необходимо добавить в PYTHONPATH вручную, если он используется вне пакетов сайта.