統一的 Python 環境：從 venv 和 Conda 到 uv

首页 » 蟒蛇 » 統一的 Python 環境：從 venv 和 Conda 到 uv

在實際專案中使用 Python 會很快揭示一個令人痛苦的事實：一個全域 Python 安裝是不夠的。 一旦你同時運行多個應用程序，就會遇到依賴衝突、版本不匹配以及經典的“在我機器上運行正常”的問題。一個應用程式需要 Django 2.2，另一個需要 Django 4.2，一個資料管道堅持使用 pandas 1.3，而一個筆記本程式則需要 pandas 2.0——將所有依賴項都安裝到系統全域範圍內，簡直就是自找麻煩。

統一且隔離的 Python 環境就是擺脫這種困境的出路。 透過結合虛擬環境，現代依賴管理工具如 點子, 康達, 詩, 管道, 數據表 以及高性能工具，例如 uv這樣，您可以為每個專案提供自己的 Python 版本和軟體包集，保持作業系統 Python 的完整性，並可靠地在機器、CI/CD 管道和生產​​伺服器之間重現設定。

為什麼統一的 Python 環境如此重要

所有環境工具的核心都是需要隔離專案之間的依賴關係。 系統級的共用 Python 安裝只能容納每個函式庫的一個版本，但實際專案中很少會統一使用同一個版本。如果應用 A 將某個套件的版本鎖定在 1.0，而應用 B 需要 3.0，那麼全域安裝其中一個必然會導致另一個無法正常運作。

虛擬環境透過建立單獨的安裝目錄來解決這個問題，每個目錄都有自己的 Python 解釋器和網站軟體包。 將每個環境視為獨立的微型 Python 宇宙：一個專案可能運行 Flask 1.1，另一個專案可能運行 Flask 2.0，彼此互不干擾。在一個環境中更新庫不會影響所有其他項目。

這種隔離在團隊環境和生產部署中至關重要。 如果沒有環境、鎖定檔案和可複現安裝，開發人員安裝的「小型」更新可能會突然導致舊版服務崩潰，或者持續整合 (CI) 作業可能通過而生產環境失敗，原因在於庫版本不匹配。環境、鎖定檔案和可復現安裝可以消除這種隨機性。

統一工作流程旨在將所有這些功能整合到一個統一的工具鏈中。 現代工具（如 uv）不再需要手動混合使用 pip、venv、virtualenv、pyenv、Conda、requirements.txt 和各種 shell 腳本，而是嘗試提供一個統一的介面來創建環境、解決依賴關係、鎖定版本、運行命令，甚至構建和發佈軟體包。

經典的 Python 虛擬環境：venv 和 virtualenv

Python 內建的隔離環境解決方案是 venv 本模組在 Python 3.3 中引入。 它自備 Python 3，所以您無需額外安裝任何軟體。 venv 環境就是一個包含 Python 解釋器、標準函式庫等的目錄。 pip 以及啟動腳本。

要建立基本的虛擬環境，通常需要執行類似這樣的命令： python -m venv .venv 從專案資料夾內部建立。這將創建一個 .venv/ 包含運行應用程式所需的一切的目錄。使用名稱 .venv 在許多檔案總管和終端機中將其隱藏，並避免與…衝突 .env 用於環境變數的檔案。

創建完成後，啟動該環境，以便 shell 使用該 Python 而不是系統 Python。 在 Windows 系統上，你可以執行類似這樣的指令。 .venv\Scripts\activate；在 Unix 或 macOS 上，您通常使用 source .venv/bin/activate其他貝殼，例如 長山壕 or 魚以及其他啟動腳本，例如 activate.csh 以及 activate.fish 提供。

啟動後，提示符通常會顯示環境名稱和 python 以及 pip 指令的作用域會自動限定在該環境中。 您可以安裝程式庫、執行腳本和偵錯程式碼，而無需修改全域套件。完成後，只需簡單地執行以下命令即可。 deactivate 返回 Python 系統。

修復前 venv 由於第三方工具的存在，開發者們廣泛使用了該工具。 virtualenv而且它仍然非常受歡迎。 virtualenv 它支援較舊的 Python 版本（包括 Python 2），並提供額外的選項，例如選擇特定的解釋器。 --python=/path/to/python透過最佳化建立更快的環境，或控制全域網站套件是否可見。

概念視圖：將環境視為程式碼的獨立廚房

一個有用的思考模型是把自己想像成一位擁有多道招牌菜的廚師。 與其不斷修改同一個主配方，不如為每個實驗保留單獨的副本。每個副本都可以使用自己的食材、技巧和時間，而不會影響原菜的味道。 Python 虛擬環境的工作原理正是如此：每個專案都有自己的配方和食材庫。

實際上，Python 虛擬環境是一個自包含的目錄樹。 它包含一個特定的 Python 解釋器、其標準函式庫以及本機環境。 site-packages 目錄和一組激活腳本。啟動後，導入和軟體包安裝只會進入該目錄樹，而不會進入全域系統檔案。

當多個專案使用同一庫的不同版本時，這種隔離機制可以防止它們發生衝突。 你可能有一個使用 Flask 1.1.2 的 Vonage + Flask 專案環境，以及另一個運行 Vonage 和 Flask 2.0.1 的環境。這兩個環境可以運作在同一台機器上，但它們的依賴項是分別維護和安裝的。

虛擬環境也是避免「但它在我的機器上運作正常」這種令人頭痛的問題的基礎。 一旦您的依賴項被整齊地捕獲和凍結，團隊成員和 CI 伺服器就可以重現完全相同的環境，從而大大減少由細微的版本差異引起的意外錯誤。

逐步建立和管理虛擬環境

虛擬環境的核心生命週期始終相同：建立、啟動、安裝軟體包、使用，然後在完成後停用。 是否使用 venv, virtualenv 或者使用 Conda，模式實際上並沒有改變——只有命令會改變。

與 virtualenv基本工作流程大致如下： 首先用…安裝它 pip install virtualenv然後進行驗證 virtualenv --version若要建立環境，請使用 virtualenv my-env 或包括 --python=/usr/bin/python3.12 針對特定解釋器。這將產生一個 my-env/ 包含 Python 二進位檔案和庫目錄的資料夾。

創建完成後，啟動環境即可開始使用。 在類別Unix系統中， source my-env/bin/activate 這樣就能解決問題；在 Windows 系統上，您可以使用下列腳本： my-env\Scripts\你的 shell 提示字元會顯示環境名稱，這樣你就可以看到哪個環境目前處於活動狀態，以及所有… pip 安裝範圍僅限於此環境。

環境啟動後，安裝依賴項就變得非常簡單。 你可以跑 pip install some-package 或點 pip 在 requirements.txt 文件 pip install -r requirements.txt如果您想取得目前已安裝軟體包的集合，請執行 pip freeze > requirements.txt 這樣其他人就可以復現相同的設定。

暫時離開那個環境後，運行 deactivate 還原到 shell 之前使用的 Python 版本。 如果您確實不再需要該環境，您可以直接刪除其目錄；該資料夾沒有什麼神奇之處，它只是磁碟上的檔案。

在虛擬環境中有效使用 pip

標準的Python套件管理器 pip是您在環境中安裝、升級和刪除庫的主要介面。 當你的環境處於活躍狀態時，每 pip 這個指令只會操作該環境，而不會操作你的系統 Python。

常用子命令包括 install, uninstall, show, list 以及 freeze. 安裝最新版本的軟體包非常簡單，就像… pip install package-name如果您需要確切的版本，可以使用 == 例如，運算符 pip install requests==2.31.0再次執行安裝程式將偵測到該版本已存在，並跳過重新安裝，除非您變更版本或新增其他內容。 --upgrade.

若要了解目前已安裝的內容， pip list 為您提供概覽，並且 pip show package-name 列印特定包裹的詳細資料。 當您需要用於部署的機器可讀快照時， pip freeze 輸出所有軟體包及其確切版本，您可以按照慣例將其寫入 requirements.txt然後，該檔案就可以與你的程式碼一起納入版本控制系統。

從 requirements.txt 這就是在別處重現某種環境的方法。 同事、CI 作業或伺服器會先建立並啟動虛擬環境，然後執行 pip install -r requirements.txt由於檔案會鎖定版本，因此在每台機器上，只要底層作業系統和 Python 版本相容，就能獲得幾乎相同的環境。

而 pip 它非常靈活，而且刻意保持底層架構，因此在其之上出現了更高層級的工具。 類似的工具 pip-tools, Poetry, Pipenv 以及 uv 以鎖定依賴項為核心，實現依賴項解析、鎖定、環境管理等自動化操作。

用於科學計算和數據密集型工作負載的 Conda 環境

對於數據科學、機器學習和數值密集型程式碼，許多團隊更喜歡 Conda 作為它們的環境和套件管理器。 Conda 與語言無關，可以安裝 Python 本身以及 BLAS、LAPACK 或 CUDA 等系統層級函式庫，這使其成為混合編譯型和解釋型元件的複雜堆疊的理想選擇。

要開始使用 Conda，您需要安裝 Anaconda 或 Miniconda。 Anaconda 預先安裝了大量軟體包，而 Miniconda 則是一個較小的安裝程序，僅包含 Conda、Python 和一些基本組件，您可以根據需要添加其他組件。大多數開發者為了保持系統精簡，會選擇 Miniconda。

創建 Conda 環境是透過以下方式完成的： conda create --name my-env（可選） python=3.11 或特定套餐，例如 numpy or pandas 在同一命令列上。 Conda 將解決依賴關係，下載適合您平台的建置版本，並將它們放置在由 Conda 本身管理的隔離環境目錄中。

啟用和停用由…處理 conda activate my-env 以及 conda deactivate. 一旦激活，即可安裝軟體包 conda install 使用 Conda 的倉庫，這些倉庫通常會提供最佳化的二進位。在許多工作流程中，你會將 Conda 與大型科學庫結合使用， pip 對於更通用的僅限 Python 的依賴項，先安裝 Conda 包，再安裝 pip 包，以盡量減少衝突。

當您需要匯出和複製完整的環境時，Conda 也表現出色。 與 conda env export > environment.yml 你不僅可以捕獲 Python 包，還可以捕獲平台和渠道等元數據。在另一台機器上， conda env create -f environment.yml 啟動一個完全相同的環境，這對於研究的可重複性和合作項目來說非常棒。

現代專案管理工具：pip + venv 與 Pipenv、Poetry、pdm 和 uv 的比較

隨著時間的推移，Python 生態系統已從「pip + virtualenv + requirements.txt」發展成為更規範的工具，統一了依賴管理、環境和包裝。 雖然經典的三人組合仍然有效，但現在許多團隊更喜歡整合式工作流程。

傳統配置依賴 pip 以及 virtualenv or venv手工製作的 requirements.txt 文件。 你需要手動創建虛擬環境，啟動它，安裝依賴項，並維護自己的凍結和升級邏輯。這種方法非常靈活，但如果團隊缺乏紀律，也很容易配置錯誤。

Pipenv 透過將依賴管理與自動虛擬環境創建結合，帶來了更高層次的介面。 它使用 Pipfile 以及 Pipfile.lock 用於描述和確定依賴項。歷史上，Pipenv 的依賴項解析和效能有時較慢，這促使人們考慮其他替代方案。

Poetry 更進一步，它提供了一個完整的專案管理器，可以在一個工具中處理依賴項、建置和發布。 它依賴現代 pyproject.toml 符合標準（PEP 621）並編寫 poetry.lock 文件格式為 TOML。 Poetry 在解決依賴關係方面通常很穩健，能夠優雅地支援版本約束，並且可以使用諸如以下命令輕鬆發佈到 PyPI： poetry publish.

pdm 是另一位也使用現代管理工具的人。 pyproject.toml 並專注於快速且符合 PEP 規範的工作流程。 它既支援虛擬環境，也支援其他方法，例如 PEP 582（本地環境）。 __pypackages__ 它提供目錄），並提供與 Poetry 相當的高級解析度和專案管理功能，同時優先考慮速度和靈活性。

在最近一個時期， uv 已經出現，它是一款高效能、統一的工具，目標是成為 Python 版的 Cargo。 它將自身定位為一個用 Rust 編寫的單一二進位文件，其中包含多種功能：依賴項解析、環境管理、Python 版本安裝、腳本執行、鎖定、建置和發布。

是什麼讓 UV 在統一的 Python 環境中脫穎而出

uv 它旨在透過提供極其快速、整合的工作流程來取代許多單獨的工具。 該專案的基準測試表明，它的速度比不使用快取的 pip 和 pip-tools 快約 8-10 倍，而使用快取時速度則快約 80-115 倍，這使得同步或重新創建環境幾乎是瞬間完成的。

uv 的核心是提供專案 API，用於處理依賴項管理、環境建立、鎖定檔案和工具執行。 類似命令 uv init 使用基本結構引導一個新項目： pyproject.toml .python-version 文件和啟動器 main.py這樣一來，幾乎無需手動設置，即可獲得一致的佈局。

當你跑步 uv add some-package，uv自動創建 .venv 環境（如有需要）更新 pyproject.toml 並寫了一篇 uv.lock 文件。 鎖定檔案記錄了每個依賴項的確切解析版本和雜湊值，從而確保安裝的可複現性。與許多其他工具不同， uv.lock 它明確支援多平台，因此同一個檔案可以在 Linux、Windows 和 macOS 上使用，同時仍保證確定性的結果。

另一個強大的功能是 uv run它可以直接在專案環境中執行命令，而無需您事先手動啟動它。 執行前，uv 會確保環境與目前環境相符。 pyproject.toml 以及 uv.lock這樣就不會意外地針對過時的依賴項執行程式碼。這減少了頻繁操作帶來的摩擦。 uv sync or uv lock 調用。

對於臨時性、一次性使用命令列工具的情況，uv 曝光 uvx 以及 uv tool run. 這些命令允許您運行類似這樣的 CLI： black, pytest or pyinstaller 無需將它們永久添加為項目依賴項。它們在持續整合 (CI) 管線或腳本中特別方便，尤其是在您只需要臨時使用某個工具的情況下。

深入了解 UV 的 pip 模式和配置

uv 的設計目標之一是成為許多 pip 工作流程的即插即用升級方案。 對於常見操作，您可以直接交換 pip install 對於 uv pip install 或使用 uv pip sync 為了與需求文件保持一致。在許多現有專案中，這使得採用這種方法既簡單又低風險。

也就是說，uv 並非有意成為 pip 的完美克隆版，其中一些差異是刻意改進的。 例如，uv 不會讀取 pip 的設定文件，例如： pip.conf or PIP_INDEX_URL相反，它使用自己的環境變量，例如 UV_INDEX_URL 並將配置儲存在 uv.toml 或在 [tool.uv.pip] 部分 pyproject.toml這樣可以減少與 pip 不斷演變的語義的意外耦合。

索引優先順序是 uv 預設加強安全性的另一個領域。 為了防止依賴混淆攻擊，uv 預設優先使用內部套件索引而非 PyPI，前提是兩者提供的套件名稱相同。有一個標誌位可以設定此功能。 --index-strategy 可以調整此行為，但安全的預設設定有助於避免企業環境中微妙的供應鏈問題。

與 pip 不同，uv 是以虛擬環境為預設安裝目標而建置的。 類似命令 uv pip install 以及 uv pip sync 將安裝到目前活動環境中或自動發現 .venv 目錄位於目前資料夾或父資料夾中。這促使您避免全域安裝，轉而從一開始就實現按項目隔離。

預設情況下，uv 會跳過編譯。 .py 至 .pyc 安裝過程中產生的字節碼有助於保持其極快的速度。 Python 仍會在需要時進行導入編譯。如果您在乎 CLI 工具或容器的啟動時間，可以使用以下指令啟用即時編譯： --compile-bytecode 安裝時預先產生字節碼。

使用 uv 實作鎖定檔案、匯出和多來源依賴關係。

这 uv.lock 該文件對於 uv 的可複現性至關重要。 這是一個 TOML 文檔，其中包含所有已解析的軟體包、確切版本、來源註冊表、哈希值、下載 URL、大小和上傳時間戳。與此相反 pyproject.toml，它表達了版本範圍和意圖（例如） requests >= 2.30），鎖定檔案描述了應該安裝的工件的精確集合。

Uv 建議您將鎖定檔案提交到版本控制系統中。 這樣，任何正在執行的開發人員或 CI 作業都可以存取這些作業。 uv sync or uv pip install 根據鎖定文件，所有受支援的作業系統都擁有完全相同的依賴項集。這大大提高了新版本發佈時的可靠性。

如果您需要與傳統工具互通，uv 可以從其鎖定檔案中匯出其他格式。 使用類似這樣的指令 uv export --format requirements.txt or uv export --format pylock.toml您可以產生經典 requirements.txt 文件或標準化 pylock.toml 其他工具也能辨識。這使得從傳統管道逐步遷移的過程更加順暢。

uv 的另一個先進功能是能夠靈活處理多個指數和來源。 In pyproject.toml 你可以定義多個 [[tool.uv.index]] 例如，新增 PyPI 映像檔、用於 GPU 建置的 PyTorch wheel 索引或內部軟體包註冊表等條目，然後將特定相依性對應到這些來源。 [tool.uv.sources].

這意味著你可以例如獲取 torch 在同一個專案檔案中，分別包含來自自訂 CUDA wheel 索引的依賴項、直接來自 Git 儲存庫的依賴項、直接來自 wheel URL 的依賴項以及可編輯模式下的本機路徑的依賴項。 它是一種強大的方法，可以集中管理複雜的依賴關係圖，而無需分散配置。

使用 UV 建置、發布和運行工具

除了依賴管理之外，uv 還負責建置和發布 Python 套件。 要使用 uv 作為構建後端，您的 pyproject.toml 需要一個 [build-system] 參考章節 uv_build， 例如： requires = ["uv_build >= 0.7.13, < 0.8"] 以及 build-backend = "uv_build"您可以在項目初始化時進行此設定。 uv init --build-backend uv.

配置完成後，運行 uv build 創造一個 dist/ 包含原始碼和 wheel 發行版的目錄。 這些工件已準備好上傳到您選擇的索引或內部註冊表。 Uv 不會自動發布它們；建置和發布是兩個獨立的步驟，以確保控制權的明確性。

要發布，您需要在以下位置新增索引配置： [[tool.uv.index]] 搭配 publish-url通常指向 PyPI 的上傳端點。 例如，您可以定義一個名為「索引」的索引 pypi - url = "https://pypi.org/simple/" 以及 publish-url = "https://upload.pypi.org/legacy/"。 然後 uv publish 會將你建立的發行版推送到那裡，類似於使用 twine 但已整合到同一工具中。

Uv 也簡化了與 CLI 工具的使用。 uvx 以及 uv tool run. 而不是安裝諸如此類的實用程序 pytest, black or pyinstaller 它們永久整合到您的環境中，您可以按需呼叫。這對於持續整合 (CI) 作業或臨時任務尤其有用，因為在這些情況下，您希望在保持專案依賴項最少的同時，仍然能夠存取豐富的工俱生態系統。

舉個具體的例子，如果你要將一個 Python 應用程式打包成 Windows 系統。 .exe 使用 pyinstaller紫外線為您提供了多種選擇。 您可以透過以下命令將 pyinstaller 新增為專案依賴項： uv add pyinstaller 然後通過以下方式運行它 uv run pyinstaller ...這樣可以確保版本鎖定並成為您環境的一部分。或者，對於快速的一次性打包任務，您可以使用 uvx pyinstaller ... 無需正式安裝即可運行。兩種方法都適用於多檔案專案；pyinstaller 會追蹤導入並打包模組、資源，甚至包括已下載的模型（例如 Whisper），前提是它們在您的程式碼或 spec 檔案中被正確引用。

將環境與 IDE、筆記本和工作流程集成

擁有強大的環境只是成功的一半——你的編輯器和工具必須真正使用它們。 像 VS Code 和 PyCharm 這樣的流行 IDE 對檢測和使用虛擬環境有著一流的支持，Jupyter 可以將它們註冊為單獨的核心。

在 VS Code 中，通常情況下，你會讓 Python 擴充功能自動發現。 .venv 項目樹中的資料夾。 然後，您可以透過命令面板中的「Python：選擇解釋器」選擇合適的解釋器。選擇後，VS Code 將使用該環境來運行其整合的終端、偵錯器和語言功能，並在您開啟新的終端時自動啟動它。

PyCharm 也提供了類似的流暢集成，它將特定的解釋器或虛擬環境與每個項目綁定在一起。 在設定對話方塊中，您可以新增一個新的 Virtualenv 環境，或指向一個現有的環境。之後，PyCharm 會自動為所有運行配置及其內建終端啟動該環境，因此您幾乎無需手動啟動。

對於 Jupyter Notebook 來說，關鍵步驟是安裝。 ipykernel 將其添加到您的環境中並註冊為核心。 運行類似程式後 python -m ipykernel install --user --name myenv這樣，你的環境在 Jupyter 內核清單中將顯示為「myenv」。這使得筆記本與相應的專案環境保持同步變得容易，避免出現細微的差異。

還有一些以筆記本為中心的工具，它們可以抽象化大部分這些功能。 整合人工智慧助理或環境自動化（例如專用 Jupyter 前端）的解決方案可以在後台自動設定和維護虛擬環境，以便資料科學家能夠更專注於實驗，而不是環境維護。

統一環境的常見陷阱和最佳實踐

即使使用成熟的工具，開發人員在管理環境時仍然會遇到一些反覆出現的問題。 常見問題包括使用錯誤的 Python 解釋器、缺少啟動腳本、Windows PowerShell 上的執行策略錯誤，或意外地安裝到全域 Python 環境而不是預期環境中。

如果你的環境最終使用了錯誤的 Python 版本，解決方法是使用正確的解釋器明確地重新建立它。 例如， python3.11 -m venv .venv or virtualenv --python=/usr/bin/python3.11 .venv 確保將正確的運行時環境整合到環境中。在以下系統上： pyenv您可以先選擇一個本機 Python 版本，然後在此基礎上建立您的環境。

當啟動腳本似乎缺失或損壞時，通常意味著環境沒有正確創建。 刪除資料夾並使用相應的檔案重新建立它。 python -m venv or virtualenv 該命令通常可以解決問題。在 Windows 系統中，如果 PowerShell 阻止了激活，您可能需要放寬目前使用者的執行策略。

為避免誤將軟體套件安裝到錯誤的 Python 版本中，請務必檢查哪個版本需要安裝軟體套件。 python 以及 pip 您正在使用。 類似命令 which python or where python （在Windows系統上） python -m site 可以確認您是否處於預期的環境。如果路徑指向系統位置而不是您的路徑，則表示您處於預期的環境中。 .venv 資料夾，小心停用並重新啟用。

良好的命名和版本控制習慣對於建立可維護的環境大有裨益。 環境名稱應清晰一致，每個專案最好只使用一個環境，​​並且永遠不要提交環境目錄本身。而是添加類似這樣的條目： .venv/ or venv/ 給你 .gitignore 並依靠鎖定文件和需求文件按需重建環境。

最後，在簡短的 README 部分中記錄如何創建和更新環境，可以為你和你的隊友節省很多猜測的時間。 一個簡單的兩行程式碼片段－例如： python -m venv .venv 其次是 pip install -r requirements.txt or uv sync – 可以大幅簡化新員工入職流程，並維持團隊中統一的 Python 環境策略的一致性。

透過將 venv、virtualenv、pip 和 Conda 等經典工具與 Poetry、pdm 和 uv 等現代管理器結合，您可以設計一個快速、可重現且安全的統一環境工作流程。 每個專案都有自己獨立的獨立環境，鎖定檔案保證了安裝的一致性，IDE 和筆記本可以無縫集成，像 uv 這樣的高效能工具將所有內容整合到一個屋簷下，將以前雜亂無章的腳本集合變成了一個連貫、可靠的 Python 開發基礎。