venv、pyvenv、pyenv、virtualenv、virtualenvwrapper、pipenv 等有什么區別？

Question

Python 3.3 在其標准庫中包含了新的包venv 。 它有什么作用，它與匹配正則表達式(py)?(v|virtual|pip)?env的所有其他包有何不同？

Answer 1

這是我對初學者的個人建議：從學習virtualenv和pip開始，這些工具可以在 Python 2 和 3 以及各種情況下使用，一旦你開始需要它們，就選擇其他工具。

現在回答這個問題：這些類似命名的事物之間有什么區別：venv、virtualenv 等？

PyPI 包不在標准庫中：

• virtualenv是一個非常流行的工具，可以為 Python 庫創建隔離的 Python 環境。 如果您不熟悉此工具，我強烈建議您學習它，因為它是一個非常有用的工具。

  它的工作原理是在一個目錄中安裝一堆文件（例如： env/ ），然后修改PATH環境變量以使用自定義bin目錄作為前綴（例如： env/bin/ ）。 python或python3二進制文件的精確副本放置在此目錄中，但 Python 被編程為首先在環境目錄中查找與其路徑相關的庫。 它不是 Python 標准庫的一部分，但得到了 PyPA（Python Packaging Authority）的正式祝福。 激活后，您可以使用pip在虛擬環境中安裝軟件包。

• pyenv用於隔離 Python 版本。 例如，您可能希望針對 Python 2.7、3.6、3.7 和 3.8 測試您的代碼，因此您需要一種在它們之間切換的方法。 激活后，它會在PATH環境變量前面加上~/.pyenv/shims ，其中有與 Python 命令（ python 、 pip ）匹配的特殊文件。 這些不是 Python 提供的命令的副本； 它們是特殊腳本，可根據PYENV_VERSION環境變量、 .python-version文件或~/.pyenv/version文件即時決定運行哪個 Python 版本。 pyenv還使用命令pyenv install使下載和安裝多個 Python 版本的過程更容易。

• pyenv-virtualenv是與pyenv同一作者的pyenv插件，讓您可以方便地同時使用pyenv和virtualenv 。 但是，如果您使用的是 Python 3.3 或更高版本， pyenv-virtualenv將嘗試運行python -m venv如果可用），而不是virtualenv 。 如果您不想要便利功能，則可以在沒有pyenv-virtualenv情況下一起使用virtualenv和pyenv 。

• virtualenvwrapper是virtualenv的一組擴展（參見docs ）。 它為您提供mkvirtualenv 、 lssitepackages等命令，尤其workon用於在不同virtualenv目錄之間切換的工作。 如果您需要多個virtualenv目錄，此工具特別有用。

• pyenv-virtualenvwrapper是與pyenv同一作者的pyenv插件，可以方便地將virtualenvwrapper集成到pyenv中。

• pipenv旨在將Pipfile 、 pip和virtualenv組合成命令行上的一個命令。 virtualenv目錄通常放置在~/.local/share/virtualenvs/XXX中，其中XXX是項目目錄路徑的哈希值。 這與virtualenv不同，其中目錄通常位於當前工作目錄中。 pipenv旨在用於開發 Python 應用程序（而不是庫）。 pipenv有其他替代品，例如poetry ，我不會在此處列出，因為這個問題僅與名稱相似的包有關。

標准庫：

• pyvenv （不要與上一節中的pyenv混淆）是 Python 3.3 到 3.7 附帶的腳本。 它從 Python 3.8中刪除，因為它有問題（更不用說令人困惑的名稱）。 運行python3 -m venv的效果與pyvenv 。

• venv是 Python 3 附帶的一個包，您可以使用python3 -m venv運行它（盡管出於某種原因，一些發行版將其分離到一個單獨的發行版包中，例如 Ubuntu/Debian 上的python3-venv ）。 它的用途與virtualenv相同，但只有一部分功能（請參閱此處的比較）。 virtualenv繼續比venv更受歡迎，特別是因為前者同時支持 Python 2 和 3。

Answer 2

我只是避免在 Python3.3+ 之后使用virtualenv ，而是使用標准發布的庫venv 。 要創建一個新的虛擬環境，您可以鍵入：

$ python3 -m venv <MYVENV>  

virtualenv嘗試將 Python 二進制文件復制到虛擬環境的 bin 目錄中。 但是，它不會更新嵌入到該二進制文件中的庫文件鏈接，因此如果您將 Python 從源代碼構建到具有相對路徑名的非系統目錄中，則 Python 二進制文件會中斷。 由於這是您制作副本可分發 Python 的方式，因此這是一個很大的缺陷。 順便說一句，要檢查 OS X 上的嵌入式庫文件鏈接，請使用otool 。 例如，在您的虛擬環境中，鍵入：

$ otool -L bin/python
python:
    @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

因此，我會避免使用virtualenvwrapper和pipenv 。 pyvenv已棄用。 pyenv似乎經常在使用virtualenv的地方使用，但我也會遠離它，因為我認為venv也可以完成pyenv的構建。

venv在 shell 中創建新的和沙盒的虛擬環境，帶有用戶可安裝的庫，並且它是多 python 安全的。

新鮮：因為虛擬環境僅從 python 附帶的標准庫開始，所以您必須在虛擬環境處於活動狀態時使用pip install重新安裝任何其他庫。

沙盒：因為這些新的庫安裝在虛擬環境之外都不可見，所以您可以刪除整個環境並重新開始，而不必擔心影響您的基本 python 安裝。

用戶可安裝的庫：因為虛擬環境的目標文件夾是在您已經擁有的某個目錄中創建的而沒有sudo ，因此您不需要sudo權限即可將庫安裝到其中。

multi-python safe ：因為當虛擬環境激活時，shell 只能看到用於構建該虛擬環境的 python 版本（3.4、3.5 等）。

pyenv與venv類似，它允許您管理多個 python 環境。 但是，使用pyenv ，您不能方便地將庫安裝回滾到某個啟動狀態，並且您可能在某些時候需要admin權限來更新庫。 所以我認為最好使用venv 。

在過去的幾年里，我在構建系統（emacs 包、python 獨立應用程序構建器、安裝程序...）中發現了許多問題，最終歸結為virtualenv的問題。 我認為當我們消除這個附加選項並且只使用venv時，python 將是一個更好的平台。

編輯：BDFL 的推文，

我使用 venv（在標准庫中）和一堆 shell 別名來快速切換。

— Guido van Rossum (@gvanrossum) 2020 年 10 月 22 日

Answer 3

更新 20200825：

在“結論”段落下方添加

我已經進入了pipenv兔子洞（它確實是一個又深又黑的洞...... ）並且由於最后一個答案是 2 年前，我覺得用 Python 虛擬信封主題的最新發展來更新討論很有用我找到了。

免責聲明：

這個答案不是關於繼續關於pipenv與venv作為信封解決方案的優點的激烈辯論 -我不認可任何一個。 這是關於PyPA認可相互沖突的標准，以及virtualenv的未來發展如何承諾完全否定在它們之間做出非此即彼的選擇。 我專注於這兩個工具正是因為它們是PyPA 指定的工具。

venv

正如 OP 所指出的， venv是一種用於虛擬化環境的工具。 不是第三方解決方案，而是原生工具。 PyPA認可venv用於創建虛擬信封：“在 3.5 版中更改：現在建議使用 venv 來創建虛擬環境”。

管道

pipenv - 與venv類似 - 可用於創建虛擬信封，但另外還包含包管理和漏洞檢查功能。 pipenv不使用requirements.txt ，而是通過pipenv提供包管理。 由於PyPA認可 pipenv 用於PACKAGE MANAGEMENT ，這似乎意味着pipfile將取代requirements.txt 。

但是： pipenv使用virtualenv作為創建虛擬信封的工具，而不是venv ，它被PyPA認可為創建虛擬信封的首選工具。

沖突標准：

因此，如果確定虛擬信封解決方案還不夠困難，我們現在有PyPA支持兩種使用不同虛擬信封解決方案的不同工具。 可以在這里找到關於venv 與 virtualenv的激烈爭論，突出了這種沖突。

解決沖突：

上述鏈接中引用的 Github 辯論引導virtualenv開發朝着在未來版本中適應venv的方向發展：

更喜歡內置 venv：如果目標 python 有 venv，我們將使用它創建環境（然后對其執行后續操作以促進我們提供的其他保證）

結論：

因此，看起來這兩種競爭的虛擬信封解決方案之間將會有一些未來的融合，但到目前為止，使用virtualenv的pipenv與venv有很大的不同。

鑒於pipenv解決的問題以及PyPA的支持，它似乎有一個光明的未來。 如果virtualenv實現了它提出的開發目標，那么選擇一個虛擬信封解決方案應該不再是pipenv或venv的情況。

更新 20200825 ：

在進行此分析時，我經常看到對Pipenv的反復批評是它沒有得到積極的維護。 確實，使用一個由於缺乏持續開發而未來可能會受到質疑的解決方案有什么意義呢？ 在經歷了大約 18 個月的枯竭期后， Pipenv再次被積極開發。 事實上，自那以后已經發布了大量的重大更新。

Answer 4

讓我們從這些工具想要解決的問題開始：

我的系統包管理器沒有我想要的 Python 版本，或者我想並排安裝多個 Python 版本，Python 3.9.0 和 Python 3.9.1、Python 3.5.3 等

然后使用 pyenv。

我想安裝和運行具有不同的、相互沖突的依賴項的多個應用程序。

然后使用 virtualenv 或 venv。 這些幾乎是完全可以互換的，不同之處在於 virtualenv 支持較舊的 python 版本並具有一些更小的獨特功能，而 venv 在標准庫中。

我正在開發 /application/ 並且需要管理我的依賴項，並管理我的項目依賴項的依賴項解析。

然后使用 pipenv 或詩歌。

我正在開發 /library/ 或 /package/ 並希望指定我的庫用戶需要安裝的依賴項

然后使用設置工具。

我使用了 virtualenv，但我不喜歡 virtualenv 文件夾分散在各種項目文件夾中。 我想要集中管理環境和一些簡單的項目管理

然后使用 virtualenvwrapper。 變體：pyenv-virtualenvwrapper 如果你也使用 pyenv。

---

不建議

• pyvenv。 這已棄用，請改用 venv 或 virtualenv。 不要與 pipenv 或 pyenv 混淆。

Answer 5

2020 年 1 月更新

@Flimm 很好地解釋了所有差異。 通常，我們想知道所有工具之間的區別，因為我們想決定什么最適合我們。 那么，下一個問題是：使用哪一個？ 我建議您選擇以下兩種官方方式之一來管理虛擬環境：

• Python Packaging 現在 推薦 Pipenv
• Python.org 現在推薦 venv

Answer 6

• pyenv - 管理不同的 python 版本，
• 所有其他人-創建虛擬環境（具有隔離的python版本並安裝了“要求”），

pipenv想要結合所有，除了以前它安裝“需求”（進入活動的虛擬環境，如果沒有活動則創建自己的）

所以也許你只會對 pipenv 感到滿意。

但我使用：pyenv + pyenv-virtualenvwrapper，+ pipenv（僅用於安裝要求的 pipenv）。

在 Debian 中：

1. apt install libffi-dev

2. 根據https://www.tecmint.com/pyenv-install-and-manage-multiple-python-versions-in-linux/安裝 pyenv，但是..

3. .. 但不是 pyenv-virtualenv 安裝 pyenv-virtualenvwrapper （可以是獨立庫或 pyenv 插件，這里是第二個選項）：

    $ pyenv install 3.9.0 $ git clone https://github.com/pyenv/pyenv-virtualenvwrapper.git $(pyenv root)/plugins/pyenv-virtualenvwrapper # inside ~/.bashrc add: # export $VIRTUALENVWRAPPER_PYTHON="/usr/bin/python3" $ source ~/.bashrc $ pyenv virtualenvwrapper

然后為您的項目創建虛擬環境（workingdir 必須存在）：

pyenv local 3.9.0  # to prevent 'interpreter not found' in mkvirtualenv
python -m pip install --upgrade pip setuptools wheel
mkvirtualenv <venvname> -p python3.9 -a <workingdir>

並在項目之間切換：

workon <venvname>
python -m pip install --upgrade pip setuptools wheel pipenv

在一個項目中，我有文件 requirements.txt，沒有修復里面的版本（如果不需要某些版本限制）。 您有 2 個可能的工具可以將它們安裝到當前的虛擬環境中： pip-tools或pipenv 。 假設您將使用 pipenv：

pipenv install -r requirements.txt

這將創建 Pipfile 和 Pipfile.lock 文件，固定版本在第二個。 如果您想在完全相同版本的地方重新安裝，那么（Pipfile.lock 必須存在）：

pipenv install

請記住，Pipfile.lock 與某些 Python 版本相關，如果您使用其他版本，則需要重新創建。

如您所見，我編寫了 requirements.txt。 這有一些問題：您也必須從 Pipfile 中刪除已刪除的包。 所以直接寫Pipfile可能會更好。

所以你可以看到我對 pipenv 的使用非常糟糕。 也許如果你用得好，它可以代替一切？

編輯 2021.01 ：我已將堆棧更改為： pyenv + pyenv-virtualenvwrapper + poetry 。 IE。 我不使用 virtualenv 或 virtualenvwrapper 的 apt 或 pip 安裝，而是安裝pyenv的插件pyenv-virtualenvwrapper 。 這是更簡單的方法。

Poetry對我來說很棒：

poetry add <package>   # install single package
poetry remove <package>
poetry install   # if you remove poetry.lock poetry will re-calculate versions

Answer 7

作為一個 Python 新手，這個問題讓我無休止地沮喪，讓我困惑了幾個月。 當我知道我將在未來幾年使用它時，我應該投資學習哪個虛擬環境和包管理器？

回答這個棘手問題的最佳文章是 Jake Vanderplas 的https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/ 。 盡管已有幾年歷史，但它提供了實用的答案以及 Python 包和虛擬環境管理器在這些最先進技術的發展過程中的歷史。

在數據科學和“大數據雲計算”社區中，我尤其感到沮喪，因為 conda 被廣泛用作 Python 和 JavaScript、SQL、Java、HTML5 和 Jupyter Notebooks 的虛擬環境管理器和全功能包管理器。

那么，當 conda 完成 pip 和 venv 變體所做的一切時，為什么還要使用 pip 呢？

答案是，“因為如果 conda 包根本不可用，您必須使用 pip。” 很多時候，所需的包僅以 pip 格式提供，沒有簡單的解決方案，只能使用 pip。 您可以學習使用conda build ，但如果您不是包維護者，那么您必須說服包所有者為每個新版本生成一個 conda 包（或自己做。）

這些基於 pip 的軟件包在許多重要和實用的方面有所不同：

• 穩定
• 到期
• 復雜
• 積極支持（相對於死亡或死亡）
• Python 生態系統“核心”與“邊緣”（即集成到 Python.org 發行版）附近的采用水平
• 易於理解和使用（適合初學者）

我將從包成熟度和穩定性的維度回答你關於兩個包的問題。

venv 和 virtualenv 是最成熟、最穩定、最受社區支持的。 從在線文檔中，您可以看到 virtualenv 截至今天的版本為 20.x。 虛擬環境

virtualenv 是一個創建隔離 Python 環境的工具。 從 Python 3.3 開始，它的一個子集被集成到標准庫的 venv 模塊下。 venv 模塊不提供這個庫的所有特性，僅舉幾個比較突出的例子：

 is slower (by not having the app-data seed method), is not as extendable, cannot create virtual environments for arbitrarily installed python versions (and automatically discover these), is not upgrade-able via pip, does not have as rich programmatic API (describe virtual environments without creating them).

virtualenvwrapper 是一組幫助人們使用 virtualenv 的腳本（它是一個維護不善的“包裝​​器”，它的最后一次更新是在 2019 年。virtualenvwrapper

我的建議是盡可能避免使用所有 pip 虛擬環境。 改用 conda。 Conda 提供了一種統一的方法。 它由專業的開源開發人員團隊維護，並有一家信譽良好的公司提供資金和商業支持的版本。 相比之下，維護 pip、venv、virtualenv、pipenv 和許多其他 pip 變體的團隊資源有限。 pip 虛擬環境的多樣性對於初學者來說是令人沮喪的。 基於 pip 的虛擬環境工具的復雜性、碎片化、邊緣和不受支持的包以及極其不一致的支持促使我使用 conda。 對於數據科學工作，我的建議是在 conda 包不存在時使用基於 pip 的虛擬環境管理器作為最后的手段。

venv 變體之間的差異仍然讓我感到害怕，因為我學習新軟件包的時間有限。 pipenv、venv、pyvenv、pyenv、virtualenv、virtualenvwrapper、詩歌和其他有幾十個差異和復雜性，需要幾天時間才能理解。 我討厭走上一條路，當維護者辭職（或太忙而無法維護它）時，對一個包的支持就會崩潰。 我只需要完成我的工作。

本着樂於助人的精神，這里有一些鏈接可以幫助您深入了解，但不要迷失在但丁的地獄（re：pip）中。

Python 虛擬環境指南

選擇“核心”Python 包來投資你的職業（長期），而不是短期完成工作）很重要。 但是，這是一個業務分析問題。 您是想簡單地完成一項任務，還是一個專業的軟件工程師構建可擴展的高性能系統，隨着時間的推移需要最少的維護工作？ 恕我直言，conda 比處理 pip-plurality 問題更容易將您帶到后者。 conda 仍然缺少 1 步 pip-package 遷移工具，這使得這成為一個沒有實際意義的問題。 如果我們可以簡單地將 pip 包轉換為 conda 包，那么 pypi.org 和 conda-forge 可以合並。 Pip 是必要的，因為 conda 包（還）不是通用的。 許多 Python 程序員要么懶得創建 conda 包，要么只用 Python 編程，不需要 conda 的語言無關/多語言支持。

conda 對我來說是天賜之物，因為它支持雲軟件工程和數據科學對 JavaScript、SQL 和 Jupyter Notebook 擴展的多語言支持的需求，並且 conda 在 Docker 和其他雲原生環境中運行良好。 我鼓勵您學習和掌握 conda，這將使您能夠回避許多基於 pip 的工具可能永遠無法回答的復雜問題。

把事情簡單化！ 我需要一個包來完成我需要的 90% 的工作，並為剩下的 10% 的邊緣情況提供指導和解決方法。

查看此處鏈接的文章，了解有關基於 pip 的虛擬環境的更多信息。

我希望這對原始海報有所幫助，並為 pip 和 conda 愛好者提供一些思考的東西。