本文的文字及圖片來源于網路,僅供學習、交流使用,不具有任何商業用途,著作權歸原作者所有,如有問題請及時聯系我們以作處理
以下文章來源于騰訊云 作者：昱良
本文先介紹虛擬環境的基礎知識以及使用方法，然后再深入介紹虛擬環境背后的作業原理，（環境：在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
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/235653.html
標籤：其他