Python的虛擬環境極大地方便了人們的生活。本指南先介紹虛擬環境的基礎知識以及使用方法，然後再深入介紹虛擬環境背後的工作原理。
注意：本指南在macOS Mojave系統上使用最新版本的Python 3.7.x。
目錄
· 爲什麼使用虛擬環境？
· 什麼是虛擬環境？
· 使用虛擬環境
· 管理環境
· 虛擬環境如何運行？
- 爲什麼使用虛擬環境？
虛擬環境爲一系列潛在問題提供簡單的解決方案，尤其是在以下幾個方面：
· 允許不同的項目使用不同版本的程序包，從而解決依賴性問題。例如，可以將Project A v2.7用於Project X，並將Package A v1.3用於Project Y。
· 通過捕獲需求文件中的所有包依賴項，使項目自包含且可重現。
· 在沒有管理員權限的主機上安裝軟件包。
· 只需要一個項目，無需在系統範圍內安裝軟件包，就能保持全局site-packages /目錄整潔。
聽起來很方便，不是嗎？開始構建更復雜的項目並與其他人協作時，虛擬環境的重要性會凸顯出來。很多數據科學家也需要熟悉虛擬環境中與多語言相關的Conda環境。
可按照先後次序來使用！
- 什麼是虛擬環境？
到底什麼是虛擬環境？
虛擬環境是用於依賴項管理和項目隔離的Python工具，允許Python站點包（第三方庫）安裝在本地特定項目的隔離目錄中，而不是全局安裝（即作爲系統範圍內的Python的一部分）。
這聽起來不錯，但到底什麼是虛擬環境呢？虛擬環境只是一個包含三個重要組件的目錄：
· 安裝了第三方庫的site-packages /文件夾。
· 系統上安裝的Python可執行文件的symlink符號鏈接。
· 確保執行Python代碼的腳本使用在給定虛擬環境中安裝的Python解釋器和站點包。
最後一點在於會發生一些意想不到的錯誤，稍後會講這一點，但現在先看看在實際中如何實際使用虛擬環境。
- 使用虛擬環境
創造虛擬環境
假設想要爲正在處理的項目創建一個名爲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沒有故障。
- 管理環境
需求文件
使我們的工作成果可被他人重新使用的最簡單方法是在項目的根目錄（頂層目錄）中加入一個需求文件。爲此，需要運行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.txtCollecting numpy==1.15.3 (from -r i (line 1))Installing collected packages: numpySuccessfully 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文件，又恢復了正常。然而另一個原因是始終要在項目中列入需求文件。
- 虛擬環境如何做到這一點？
想了解更多有關虛擬環境的信息嗎？比如，活動環境如何使用正確的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 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