2014-01-12 92 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解決方案一樣,感覺有點冒險,而且這是一個額外的設置步驟,可以讓其他開發人員(以及持續集成系統等)以及他們需要的東西在使用依賴於新軟件包的新版本時進行維護和更新。您可以編寫一個腳本來設置「運行」目錄,但您需要記住運行該腳本,並在軟件包列表發生更改時重新運行該腳本。一旦您檢出代碼,就會自動找到正確的路徑。 –