python - 修改 sys.path 是处理项目特定模块的最佳方式吗

Question

我正在用python（重新）编写支持大型多语言项目的测试工具的一部分，这些工具与项目本身一起存储。在某些时候，很明显可以将某些代码重构到自己的包中。但是这应该存储在哪里以便在 python 工具之间共享呢？

在 python 路径中，有一个公司范围的 python-lib 目录，但它与数千人共享真正只对数十人重要的东西，更重要的是，它不是特定于项目的。

对于 c 测试工具，我们使用LD_LIBRARY_PATH指向我们的测试库，或者指向我们自己构建的库，或者指向一些自动构建输出。我可以修改sys.path以包含我想要的任何目录，并且表现得有点像LD_LIBRARY_PATH，除了对我的队友来说更容易。

这似乎不是pythonic。我知道 virtualenv，虽然不是很了解，但我有这些担忧：

• 这是否存储库的多个副本，或者它是 simlinked？Python 库的大小可以忽略不计，但对于我们非常大的存储库，IT 仍然不赞成。
• 相关的，这些库是否保持同步，因此每个工具都可以修复错误？
• 队友不想运行额外的命令，./gen_test_stimulus最好，也env LD_LIBRARY_PATH=../testlib可以。多个命令将面临一些阻力。将 virtualenv 命令包装在 bash 脚本中是解决此问题的方法吗？

标签： pythonvirtualenv

Answer 1

如果这仅用于测试目的，PYTHONPATH那么在运行测试代码时更新您的 Python 大致相当于更新LD_LIBRARY_PATH以测试 C 代码。以几乎相同的方式LD_LIBRARY_PATH将一些目录推送到共享对象查找路径的前面，PYTHONPATH将特定目录推送到前面sys.path，并且从 Python 开始运行的那一刻起就这样做（所以你知道没有任何奇怪的site触发导入可能需要在您有时间sys.path在主模块中更新之前放置）。

不赞成将其用于生产（除其他外，Python 2 和 3 都读取相同的环境变量，因此如果该位置的任何代码与两个版本不兼容，则可能会导致问题），但对于测试代码，这并不比调整更不合理LD_LIBRARY_PATH。

虚拟环境可能会起作用，但前提是您可以以某种方式在公司范围内发布 virtualenv；他们存储本地库的完整副本，并且（默认情况下）阻止访问其他站点范围内安装的软件包（以提供干净的环境）。以测试为中心的 virtualenv 可能希望通过允许访问系统模块的开关，以便它充当系统的补充，而不是替代。

在类似 shell 中激活 virtualenvsbash只是一个 running 的问题source /path/to/virtualenv/bin/activate，而停用它们只是在运行deactivate（当activate脚本被source编辑时，它作为一个函数添加到你的 shell 中）。它们通常比修改更安全PYTHONPATH（除此之外，它们对 Python 的每个 major.minor 版本使用特定于版本的子目录，因此您不会意外在 2.7 上运行 3.6 特定代码），但您确实需要编写您的测试代码作为真正的包（包含setup.py文件和所有）以正确管理它们。我个人认为这是值得的（你最终需要学习 Python 的打包机制），但这是一个更高的初始技能栏。