virtualenv 是管理 python 工程的利器,它可以很好的幫你維護專案中的依賴,使用 virtualenv,還能保持 global 庫的乾淨、不會被不同專案中的第三方庫所汙染。
virtualenv 的預設功能簡單好用,可一旦涉及到多人協作,或部署到不同的環境中時,錯誤的使用 virtualenv 會給你帶來一些麻煩,從而你需要花很多時間在解決這些問題上。本文的目的就是總結過去使用 virtualenv 的經驗,希望能幫你找到一種正確的開啟方式。
首先,建立一個空的 virtualenv 時,你的目錄中會包含以下檔案和目錄
drwxr-xr-x 7 fengyajie staff 224B Mar 21 22:49 .
drwxr-xr-x 8 fengyajie staff 256B Mar 21 20:28 ..
lrwxr-xr-x 1 fengyajie staff 83B Mar 21 22:49 .Python -> /usr/local/Cellar/...
drwxr-xr-x 16 fengyajie staff 512B Mar 21 22:49 bin
drwxr-xr-x 3 fengyajie staff 96B Mar 21 22:49 include
drwxr-xr-x 3 fengyajie staff 96B Mar 21 22:49 lib
-rw-r--r-- 1 fengyajie staff 61B 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 映象中。顯然,這種一致性不僅可以提高開發效率,還可以提高後續的運維效率。
相關文章:
參考: