我（用Python编写）部分支持大型多语言项目的测试工具，这些项目存储在项目本身旁边。在某些时候，很明显可以将某些代码重构为自己的程序包。但是，应该将其存储在哪里以在python工具之间共享？
在python路径中，有一个全公司范围的python-lib目录，但该目录与成千上万个共享，实际上仅对数十个人重要，更重要的是，它与项目无关。
对于c测试工具，我们使用LD_LIBRARY_PATH指向我们的测试库，或者指向我们自己的库构建，或者指向一些自动构建输出。我可以修改sys.path以包括我想要的任何目录，并且行为类似LD_LIBRARY_PATH，但对我的队友来说更容易。
这似乎不是pythonic。我了解virtualenv，尽管了解不多，但我有以下担忧：
./gen_test_stimulus最好，env LD_LIBRARY_PATH=../testlib没问题。多个命令将面临一些阻力。将virtualenv命令包装在bash脚本中是解决此问题的方法吗？答案 0 :(得分：1)
如果这仅是出于测试目的，则在运行测试代码时更新PYTHONPATH的Python大致等同于更新LD_LIBRARY_PATH以测试C代码。 LD_LIBRARY_PATH用类似的方式将某些目录推送到共享对象查找路径PYTHONPATH pushes specific directories to the front of sys.path的最前面，并且从Python开始运行的那一刻起就这样做了（所以您知道没有任何奇怪的{{ 1}}触发了导入，这些导入可能在您有时间更新主模块中的site之前进行。
不赞成将其用于生产（此外，Python 2和3读取相同的环境变量，因此如果该位置的任何代码与两个版本都不兼容，则可能导致问题）。测试代码，这比调整sys.path更加合理。
虚拟环境可能有效，但前提是您可以以某种方式在全公司范围内发布virtualenv。他们存储其本地库的完整副本，并且（默认情况下）阻止访问其他站点范围内已安装的软件包（以提供一个干净的环境）。以测试为中心的virtualenv可能希望通过允许访问系统模块的开关，因此它是对系统的补充，而不是替代。
在类似LD_LIBRARY_PATH的shell中激活virtualenvs只是运行bash的问题，而停用它们只是在运行source /path/to/virtualenv/bin/activate（当{{ 1}}脚本是deactivate版）。通常，它们比修改activate更安全（此外，它们为每个major.minor版本使用特定于版本的子目录，因此您不会在2.7上意外地运行3.6特定代码），但是确实需要将您的测试代码编写为真实的程序包（包含source文件和所有文件），以正确管理它们。我个人认为这是值得的（您最终将需要学习Python打包机制），但这 是更高的初始技能。