Python 工程管理及 virtualenv 的遷移
virtualenv 是管理 python 工程的利器，它可以很好的幫你維護專案中的依賴，使用 virtualenv，還能保持 global 庫的乾淨、不會被不同專案中的第三方庫所汙染。
virtualenv 的預設功能簡單好用，可一旦涉及到多人協作，或部署到不同的環境中時，錯誤的使用 virtualenv 會給你帶來一些麻煩，從而你需要花很多時間在解決這些問題上。本文的目的就是總結過去使用 virtualenv 的經驗，希望能幫你找到一種正確的開啟方式。
首先，建立一個空的 virtualenv 時，你的目錄中會包含以下檔案和目錄
drwxr-xr-x7 fengyajiestaff224B Mar 21 22:49 . drwxr-xr-x8 fengyajiestaff256B Mar 21 20:28 .. lrwxr-xr-x1 fengyajiestaff83B Mar 21 22:49 .Python -> /usr/local/Cellar/... drwxr-xr-x16 fengyajiestaff512B Mar 21 22:49 bin drwxr-xr-x3 fengyajiestaff96B Mar 21 22:49 include drwxr-xr-x3 fengyajiestaff96B Mar 21 22:49 lib -rw-r--r--1 fengyajiestaff61B Mar 21 22:49 pip-selfcheck.json 複製程式碼
接著當你執行source bin/activate
後，你安裝的依賴都會在lib
目錄下，這一點很誘人，會讓你覺得一切盡在掌握，因為該應用程式所需要的一切庫檔案全在這個 app 的根目錄下，所以當這個應用需要部署時，為了避免產生ImportError: No module named xxx
錯誤，你會很容易的想到將本地這個 app 目錄打包，然後放到遠端伺服器或容器中去執行。
當你這麼做時，你會發現雖然在遠端是可以執行source bin/activate
命令以進入 virtualenv ，但此時你引用的 python 可執行檔案卻並不是${app}/bin/pyhton
，而是 global 環境中的那個/usr/bin/python
，所以${app}/lib
下的所有依賴包路徑仍然是沒有被包含進sys.path
的。
這時，你才發現自己的假設是錯誤的，並開始懷疑自己使用 virtualenv 的方式存在問題，於是便 google 各種解決方案，但專案已處於部署階段，時間緊迫，你很可能找不到最優的辦法，只能退而求其次，尋求次優解，畢竟依賴包都在嘛，改下sys.path
不就好了嘛？確實很容易想到這種方法，但又不想手動改，那就寫個程式改吧，也不難：
# set_sys_path.py def set_sys_path(): import sys for path in sys.path: if os.path.split(path)[1] == 'site-packages': home = os.path.abspath(os.path.dirname(__file__)) pypath = os.path.join(home, 'lib/python2.7') pypath_sitepackage = os.path.join(home, 'lib/python2.7/site-packages') pth = os.path.join(path, 'pth.pth') with open(pth, 'w') as f: f.write("%s\n" % pypath) f.write("%s\n" % pypath_sitepackage) if __name__ == "__main__": set_sys_path() 複製程式碼
上面的程式很簡單，它將${app}/lib/python2.7
和${app}/python2.7/site-packages
兩個依賴路徑寫到pth.pth
檔案中，並將該檔案mv
到 global 的site-packages
目錄下，這樣當你啟動 global 的 python 時，會自動將pth.pth
裡的路徑新增到sys.path
下，這樣只需要在啟動你的 app 之前，執行該指令碼即可，如下：
$ python set_sys_path.py $ python main.py 複製程式碼
問題暫時解決了，這次你的 app 也順利釋出了；但還沒結束，我們希望在測試機叢集上把 app 的自動化測試做起來，在做自動化測試時，系統會隨機給你分配一臺機器資源，當測試完成後，資源會被回收。你心想，這仍然很簡單嘛，本地測試已經覆蓋得很全了，只要自動化系統利用 git 把程式碼拉下來，先執行set_sys_path.py
設定sys.path
，再執行python test.py
（測試入口）就可以了。
可這時又出現問題了，自動化測試在執行set_sys_path.py
時，報Permission denied
錯誤，原因是測試機為了保持環境不被汙染，不允許你將pth.pth
複製到 global 的site-packages
下。
遇到這個問題怎麼辦？其實也很容易解決：我們都知道 python 中有個環境變數PYTHONPATH
可以用來設定sys.path
，既然沒有寫檔案的許可權，那定義環境變數總該可以吧：
$ export PYTHONPATH=$PYTHONPATH:${app}/lib/python2.7:${app}/lib/python2.7/site-packages $ python main.py 複製程式碼
果然可行，你再一次「順利」的完成了需求。
經歷過多次折騰後，我們發現這種使用 virtualenv 和修改sys.path
的方法不算很好，還容易出錯。於是開始思考最初的那個問題，virtualenv 該怎麼遷移？有沒有更好的辦法？答案肯定是有的，在此之前，我們先仔細觀察 virtualenv 產生的檔案，會發現其中有 28 個軟連線，它們的原始檔均在 global 庫中，如下所示
$ find . -type l ./.Python ./bin/python ./bin/python2 ./include/python2.7 ./lib/python2.7/lib-dynload ./lib/python2.7/encodings ... 複製程式碼
所以，當你把整個 virtualenv 打包，放到另一個環境中執行時，肯定是會失敗的，因為軟連線失效了，於是，再一次證實這種把整個 virtualenv 打包的方法，實際上是錯誤的，virtualenv 就只是一個 local 方案，而不是讓你可以「處處執行」的工具。
但 virtualenv 的隔離功能，可以讓你只關注專案範圍內的依賴包，所以我們可以利用pip freeze
命令，將專案內的依賴儲存到一個叫requirements.txt
的檔案中，這樣在任何其他環境，我們只要根據requirements.txt
檔案來安裝專案所需的依賴包，即可將本地的執行環境克隆出來，而且這種克隆出來的環境更純粹，不會受到源環境或 global 庫的影響，沒有不確定性。下面我們用一個例子來具體說明下：
假設 Bob 和 Alice 同在一個團隊，他們決定使用 python 來開發新專案，一開始，Bob 在 github 上建立了一個新 repo，並在本地初始化它：
# 從 github clone 專案 $ git clone https://github.com/your_group/your_repo.git $ cd your_repo # 建立並進入 virtualenv $ virtualenv . $ source bin/activate # 修改 .gitignore，過濾掉 virtualenv 產出的檔案 $ cat .gitignore *.py[cod] __pycache__/ .Python bin/ include/ lib/ pip-selfcheck.json # 在本地安裝基本依賴，例如 Flask、gevent、gunicorn 等 $ pip install Flask gevent gunicorn -i https://pypi.mirrors.ustc.edu.cn/simple/ # 將本地依賴寫入 requirements.txt $ pip freeze > requirements.txt # 將變更提交到 github $ git add . $ git commit -m "init project" $ git push origin master # 繼續開發 # ... 複製程式碼
Bob 完成了初始化，實際上他只提交了.gitignore
和requirements.txt
兩個檔案到 git 中，之後 Alice 也可以加入進來了：
# 從 github clone 專案 $ git clone https://github.com/your_group/your_repo.git $ cd your_repo # 建立並進入 virtualenv $ virtualenv . $ source bin/activate # 根據 requirements.txt 檔案下載專案所需的依賴 $ pip install Flask gevent gunicorn -i https://pypi.mirrors.ustc.edu.cn/simple/ # 繼續開發 # ... 複製程式碼
可以看到，通過這樣的步驟，Bob 和 Alice 不僅有了一摸一樣的開發環境，還能最小化 git 倉庫的大小，且按照這樣的思路，他們還可以把相同的環境克隆到測試機上，以及 Docker 映象中。顯然，這種一致性不僅可以提高開發效率，還可以提高後續的運維效率。
相關文章：
參考：