本文先介紹虛拟環境的基礎知識以及使用方法,然後再深入介紹虛拟環境背後的工作原理。(環境:在macOS Mojave系統上使用最新版本的Python 3.7.x)
目錄
- 為什麼使用虛拟環境?
- 什麼是虛拟環境?
- 使用虛拟環境
- 管理環境
- 虛拟環境如何運作?
1. 為什麼使用虛拟環境?
虛拟環境為一系列潛在問題提供簡單的解決方案,尤其是在以下幾個方面:
- 允許不同的項目使用不同版本的程式包,進而解決依賴性問題。例如,可以将Project A v2.7用于Project X,并将Package A v1.3用于Project Y。
- 通過捕獲需求檔案中的所有包依賴項,使項目自包含且可重制。
- 在沒有管理者權限的主機上安裝軟體包。
- 隻需要一個項目,無需在系統範圍内安裝軟體包,就能保持全局site-packages /目錄整潔。
聽起來很友善,不是嗎?開始建構更複雜的項目并與其他人協作時,虛拟環境的重要性會凸顯出來。很多資料科學家也需要熟悉虛拟環境中與多語言相關的Conda環境。
可按照先後次序來使用!
2. 什麼是虛拟環境?
到底什麼是虛拟環境?
虛拟環境是用于依賴項管理和項目隔離的Python工具,允許Python站點包(第三方庫)安裝在本地特定項目的隔離目錄中,而不是全局安裝(即作為系統範圍内的Python的一部分)。
這聽起來不錯,但到底什麼是虛拟環境呢?虛拟環境隻是一個包含三個重要元件的目錄:
- 安裝了第三方庫的site-packages /檔案夾。
- 系統上安裝的Python可執行檔案的symlink符号連結。
- 確定執行Python代碼的腳本使用在給定虛拟環境中安裝的Python解釋器和站點包。
最後一點在于會發生一些意想不到的錯誤,稍後會講這一點,但現在先看看在實際中如何實際使用虛拟環境。
3. 使用虛拟環境
創造虛拟環境
假設想要為正在處理的項目建立一個名為test-project/的虛拟環境,該項目具有以下目錄樹:
test-project/
├── data
├── deliver # Final analysis, code, & presentations
├── develop # Notebooks for exploratory analysis
├── src # Scripts & local project modules
└── tests
需要執行venv子產品,它是Python标準庫的一部分。
% cd test-project/
% python3 -m venv venv/ # Creates an environment called venv/
注意:可使用不同的環境名稱替換“venv/”。
瞧!虛拟環境誕生了。現在項目變成:
test-project/
├── data
├── deliver
├── develop
├── src
├── tests
└── venv # There it is!
提醒:虛拟環境本身就是一個目錄。
唯一要做的事情是通過運作前面提到的腳本來“激活”環境。
% source venv/bin/activate
(venv) % # Fancy new command prompt
現在我們位于活動的虛拟環境中(由指令提示符訓示,字首為活動環境的名稱)。
我們會像往常一樣處理項目,確定項目與系統的其他部分完全隔離。在虛拟環境中,我們無法通路系統範圍的站點包,并且無法在虛拟環境之外通路安裝包。
完成項目工作時,可以通過以下代碼退出環境:
(venv) % deactivate
% # Old familiar command prompt
安裝包
預設情況下,隻在新環境中安裝pip和setuptools。
(venv) % pip list # Inside an active environmentPackage Version
---------- -------
pip 19.1.1
setuptools 40.8.0
如果想要安裝第三方庫的特定版本,比如numpyv1.15.3,可像往常一樣使用pip。
(venv) % pip install numpy==1.15.3
(venv) % pip listPackage Version
---------- -------
numpy 1.15.3
pip 19.1.1
setuptools 40.8.0
現在可在腳本或活動的Python shell中導入numpy。例如,假設項目包含以下幾行腳本tests / imports-test.py。
#!/usr/bin/env python3
import numpy as np
直接從指令行運作這個腳本時,可得到:
(venv) % tests/imports-test.py
(venv) % # Look, Ma, no errors!
成功。腳本導入numpy沒有故障。
4. 管理環境
需求檔案
使我們的工作成果可被他人重新使用的最簡單方法是在項目的根目錄(頂層目錄)中加入一個需求檔案。為此,需要運作pip freeze,以下列出已安裝的第三方軟體包及其版本号:
(venv) % pip freeze
numpy==1.15.3
并将輸出寫入檔案,我們稱之為requirements.txt。
(venv) % pip freeze > requirements.txt
更新軟體包或安裝新軟體包時,都可使用相同的指令重寫需求檔案。
現在,任何共享項目的人都可以使用requirements.txt檔案,通過複制環境以在系統上運作項目。
複制環境
等等——究竟是怎麼做到的?
想象一下,我們的隊友Sara從團隊的GitHub存儲庫中删除了測試項目。在她的系統上,項目的目錄樹如下所示:
test-project/
├── data
├── deliver
├── develop
├── requirements.txt
├── src
└── tests
注意到有點不尋常的東西了嗎?是的,沒錯!沒有venv /檔案夾。
我們已經将它從團隊的GitHub存儲庫中删除,因為它的存在可能會引起麻煩。
這就是使用requirements.txt檔案對複制項目代碼至關重要的一個原因。
要在機器上運作測試項目,Sara需要做的就是在項目的根目錄中建立一個虛拟環境:
Sara% cd test-project/
Sara% python3 -m venv venv/
并使用pip install -r requirements.txt将項目的依賴項安裝在活動的虛拟環境中。
Sara% source venv/bin/activate
(venv) Sara% pip install -r requirements.txt
Collecting numpy==1.15.3 (from -r i (line 1))
Installing collected packages: numpy
Successfully installed numpy-1.15.3
現在,Sara系統上的項目環境與我們的系統完全相同。很整潔,不是嗎?
故障排除
可惜事情并不總是按計劃進行,總會遇到一些問題。也許錯誤地更新了特定的站點包後發現自己處于Dependency Hell的第九級,無法運作單行項目代碼。也許它沒那麼糟糕,可能你會發現自己竟處于第七級。
無論你發現自己處于何種程度,解決問題并再次看到希望的最簡單方法是重新建立項目的虛拟環境。
% rm -r venv/ # Nukes the old environment
% python3 -m venv venv/ # Makes a blank new one
% pip install -r requirements.txt # Re-installs dependencies
大功告成,多虧了requirements.txt檔案,又恢複了正常。然而另一個原因是始終要在項目中列入需求檔案。
5. 虛拟環境如何做到這一點?
想了解更多有關虛拟環境的資訊嗎?比如,活動環境如何使用正确的Python解釋程式并如何找到合适的第三方庫?
echo $ PATH
這一切都歸結為PATH的價值,它告訴shell使用什麼Python執行個體以及在哪裡尋找網站包。在基礎shell中,PATH看起來或多或少是這樣表現的。
% echo $PATH
/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin
調用Python解釋器或運作.py腳本時,shell會按順序搜尋PATH中列出的目錄,直到遇到Python執行個體。要檢視PATH首先找到的Python執行個體,請運作which python3。
% which python3
/usr/local/bin/python3 # Your output may differ
通過站點子產品(這是Python标準庫的一部分)查找此Python執行個體查找站點包的位置也很容易。
% python3 # Activates a Python shell
>>> import site
>>> site.getsitepackages() # Points to site-packages folder[ /usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages ]
運作腳本venv / bin / activate修改PATH,以便shell在搜尋系統的全局二進制檔案之前搜尋項目的本地二進制檔案。
% cd ~/test-project/
% source venv/bin/activate
(ven) % echo $PATH~/test-project/venv/bin:/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin
現在shell知道如何使用項目的本地Python執行個體:
(venv) % which python3
~/test-project/venv/bin/python3
在哪裡可以找到項目的本地站點包?
(venv) % python3
>>> import site
>>> site.getsitepackages()[ ~/test-project/venv/lib/python3.7/site-packages ] # Ka-ching
理智檢查
還記得以前的tests / imports-test.py腳本嗎?看起來是下面這樣:
#!/usr/bin/env python3
import numpy as np
我們能夠在活動環境中運作此腳本,不出現任何問題,是因為環境中的Python執行個體能夠通路項目的本地站點包。
如果運作從項目的虛拟環境外部而來的相同腳本會發生什麼?
% tests/imports-test.py # Look, no active environmentTraceback (most recent call last):
File "tests/imports-test.py", line 3, in <module>
import numpy as npModuleNotFoundError: No module named numpy
是的,出現了一個錯誤,但我們應該這樣做。如果我們不這樣做,那就意味着我們能夠從項目外部通路項目的本地站點包,進而破壞了擁有虛拟環境的整個目的。出現錯誤的事實證明我們的項目與系統的其他部分完全隔離。
環境的目錄樹
有一件事可以幫助整理所有這些資訊,即清楚地了解環境目錄樹的外觀。
test-project/venv/ # Our environment s root directory
├── bin
│ ├── activate # Scripts to activate
│ ├── activate.csh # our project s
│ ├── activate.fish # virtual environment.
│ ├── easy_install
│ ├── easy_install-3.7
│ ├── pip
│ ├── pip3
│ ├── pip3.7
│ ├── python -> /usr/local/bin/python # Symlinks to system-wide
│ └── python3 -> python3.7 # Python instances.
├── include
├── lib
│ └── python3.7
│ └── site-packages # Stores local site packages
└── pyvenv.cfg