2014-01-12 69 views
2

我在Python中处理几个不同的程序和包。它们各自在自己的Git存储库中开发,但通常需要导入其他包中定义的模块。例如,在开发过程中,目录结构如下所示:在开发期间设置Python路径

src/ 
|-- project-a/ 
| |-- client.py 
| |-- server.py 
| |-- package-a 
|  |-- __init__.py 
|  |-- module.py 
|-- project-b/ 
| |-- package-b 
| | |-- __init__.py 
| | |-- other_module.py 
| |-- package-c 
|  |-- __init__.py 
|  |-- third_module.py 
|-- project-c/ 
    |-- server1.py 
    |-- server2.py 
    |-- package-d/ 
    |-- package-e/ 
    |-- package-f/ 

当它们都安装完毕后,它们工作正常;它们都安装成每个软件包都位于Python路径中,并且可以根据需要从它们导入。

但是,在开发过程中,我希望每个开发版本都在我的Python路径中,而不是安装的版本。在进行更改时,我不想安装要更改的每个软件包来测试它,我希望更改立即生效。这意味着我的Python路径需要包括目录project-aproject-b

我们目前的解决方案是只是有在顶级在shell的environment.bash,您源,并将其设置PYTHONPATH。这很好,但我经常忘记这么做;由于这是一个客户端服务器应用程序,通过服务器之间的通信,我需要至少有四个窗口可以打开到不同的虚拟机来运行它,而且我经常会忘记至少在其中一个环境中发布environment.bash,这导致我尝试调试奇怪的行为,直到我意识到我正在导入错误的东西。

另一种解决方案是从顶级client.py或server.py中设置sys.path。这对于直接启动它们可以很好地工作,但我还需要设置用于运行Pylint或Sphinx等工具的路径,该解决方案不会涵盖该路径。我还需要一种方法来区分从源代码运行(当我希望路径包括.../project-b)并运行安装的版本(应该使用标准路径而不进行修改)。

另一个选择是将有一个Makefile其适当地设置PYTHONPATH各种目标像make run-servermake lintmake doc,等等。这对于那些不需要任何选项的目标来说是可以的,但对于运行带有参数的客户端来说会很不方便。 make run-client ARGS='foo bar'是一个相当麻烦的方式来调用它。

在开发过程中是否有任何常见的设置Python路径的方式,以便像Pylint和Sphinx这样的可执行文件和工具可以正确地选取它,而不会干扰它在安装时的行为方式?

回答

2

一个简单的解决方案是简单地在单独文件夹中的每个模块的目录中进行符号链接,然后从那里运行。通过这种方式,Python将它们全部放在同一个位置,即使实际的源代码位于不同的存储库中。

src/ 
|-- project-a/ 
| |-- client.py 
| |-- server.py 
| |-- package-a 
|  |-- __init__.py 
|  |-- module.py 
|-- project-b/ 
    |-- package-b 
    | |-- __init__.py 
    | |-- other_module.py 
    |-- package-c 
     |-- __init__.py 
     |-- third_module.py 
run/ 
|-- client.py --> ../src/project-a/client.py 
|-- server.py --> ../src/project-a/server.py 
|-- package-a/ --> ../src/project-a/package-a/ 
|-- package-b/ --> ../src/project-b/package-b/ 
|-- package-c/ --> ../src/project-b/package-c/ 
+0

有趣的想法。这是一个潜在的解决方案,虽然这意味着我的工作目录需要“运行”,而不是“实际上正在处理的项目”(其中包含我的Git回购,“Makefile”和等等)。 –

+0

是的,但是如果你“打开了4个窗口”,那么当你的编辑器窗口在源目录中时,没有理由让其他窗口不能在'run /'目录中。 – Amber

+0

是的。这绝对是一个值得考虑的解决方案,但它与Makefile解决方案一样,感觉有点冒险,而且这是一个额外的设置步骤,可以让其他开发人员(以及持续集成系统等)以及他们需要的东西在使用依赖于新软件包的新版本时进行维护和更新。您可以编写一个脚本来设置“运行”目录,但您需要记住运行该脚本,并在软件包列表发生更改时重新运行该脚本。一旦您检出代码,就会自动找到正确的路径。 –