另一个开发人员和我不同意是否应该使用python path或sys.path来允许python在用户(如development)目录中查找python包。

我们有一个具有典型目录结构的python项目：

在script.py中，我们需要执行import package.lib。当包安装在站点包中时，script.py可以找到package.lib。

但是，在用户目录中工作时，还需要做一些其他的事情。我的解决方案是将我的pythonpath设置为包含"~/project"。另一个开发人员希望将这一行代码放在script.py的开头：

号

以便python可以找到package.lib的本地副本。

我认为这是一个坏主意，因为这一行只对从本地副本运行的开发人员或人员有用，但是我不能给出一个好的理由来解释为什么它是一个坏主意。

我们应该使用pytohnpath、sys.path还是可以？

如果修改路径的唯一原因是开发人员使用他们的工作树，那么您应该使用安装工具为您设置环境。virtualenv非常流行，如果您使用的是安装工具，那么只需运行setup.py develop就可以在当前的python安装中半安装工作树。

我讨厌Python。我发现在每个用户的基础上设置(特别是对守护进程用户)并跟踪项目文件夹的移动是脆弱和烦人的。我更愿意在独立项目的调用脚本中设置sys.path。

然而，sys.path.append并不是这样做的方法。你可以很容易地得到重复的文件，而且它不会整理出.pth文件。更好(更易读)：site.addsitedir。

通常情况下，script.py不是更合适的地方，因为它位于您希望在路径上提供的包中。库模块当然不应该接触到sys.path本身。相反，您通常会在包外有一个散列脚本，用于实例化和运行应用程序，在这个简单的包装脚本中，您可以放置部署细节，如sys.path冻结。

一般来说，我会考虑设置一个环境变量(如pythonpath)做一个坏习惯。虽然这对于一次性调试可能很好，但将其用作定期练习可能不是个好主意。

环境变量的使用会导致一些情况，例如"它对我有效"，而else报告代码库中的问题。也可以用同样的方法测试环境也会导致一些情况，比如测试在特定的开发人员，但在某些人启动测试时可能会失败。

除了前面提到的许多其他原因之外，您还可以指出硬编码

埃多克斯1〔9〕

是脆弱的，因为它假定script.py的位置——只有当script.py位于项目/包中时，它才会工作。如果用户决定将/copy/symlink script.py(几乎)移动到其他任何地方，它将中断。

我认为，在本例中，使用pythonpath是一件更好的事情，主要是因为它不会引入(有问题的)不必要的代码。

毕竟，如果你想到它，你的用户不需要sys.path的东西，因为你的包将被安装到站点包中，因为你将使用一个打包系统。

如果用户选择从"本地副本"运行(如您所说)，那么我观察到，通常的做法是声明，如果在站点包外使用，包需要手动添加到pythonpath。