PYTHONPATH与sys.path

Question

另一位开发人员和我在是否应该使用PYTHONPATH或sys.path来允许Python在用户(例如开发)目录中找到Python包的问题上意见不一。

我们有一个具有典型目录结构的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。我发现在每个用户的基础上设置(特别是对守护程序用户)和跟踪项目文件夹的移动是很脆弱和恼人的。我更愿意在独立项目的调用脚本中设置sys.path。

然而，sys.path.append不是解决这个问题的方法。你可以很容易地得到副本，而且它不会整理.pth文件。更好(也更具可读性)：site.addsitedir。

而且script.py通常不是更合适的地方，因为它在您想要在路径上提供的包中。库模块当然不应该接触到sys.path本身。相反，你通常会在包之外有一个散列脚本，用来实例化和运行应用程序，在这个简单的包装器脚本中，你会放入像sys.path-frobbing这样的部署细节。

Answer 3

一般来说，我认为设置环境变量(如PYTHONPATH)是一种糟糕的做法。虽然这对于一次性调试来说可能很好，但是使用如下代码

常规的实践可能不是一个好主意。

使用环境变量会导致像"it works for me“这样的情况，当有人

else报告代码库中的问题。此外，测试环境也可能会有相同的做法，导致测试对于特定的开发人员运行良好，但当某人启动测试时可能会失败。