摘要

此 PEP 建議 pip 等套件安裝程式在 Python 3.13+ 版本中，預設要求使用虛擬環境。

PEP 撤回

在此 PEP 的討論過程中，顯而易見的是，pip 的使用者體驗（UX）變更並不像提案中所述受 PEP 控制。同時也清楚的是，有大量使用者依賴於混合使用 pip 管理的依賴項與其他工具管理的依賴項（最顯著的情況是使用 Conda 時）。

此外，提議變更所帶來的大部分好處，都可以透過 PEP 668（在撰寫本文時已接受並實作）來實現。它讓 Python 解譯器的重新分發者能夠控制是否要求使用者必須使用虛擬環境、向使用者呈現什麼訊息，以及該變更應如何對其使用者逐步推行。

由於使用 pip 強制執行虛擬環境是本 PEP 的主要焦點，因此撤回本 PEP 比將其重新聚焦於其他主題更為合適。

未來若有 PEP 來解決虛擬環境命名慣例的問題/爭議仍是適當的，但任何此類嘗試都值得作為一個新的 PEP 重新開始，並專注於建立此類慣例的好處，而非強制執行它。

動機

Python 虛擬環境是 Python 開發流程中不可或缺的一部分。然而，由於它們是「選擇性加入（opt-in）」的功能，因此需要額外的努力，並要求使用者二選一：

• 採取明確步驟來啟用/停用虛擬環境
• 使用 <path-to-venv>/<bin-path>/<executable> 來執行檔案

對於新使用者來說，不使用虛擬環境時，事情看起來運作正常——直到出問題為止。此外，在不同平台上啟用虛擬環境的語法和機制略有不同。這使得虛擬環境的入門變得複雜，因為現在必須解釋虛擬環境為何有用及其相關背景，才能證明在工作流程中增加額外步驟是合理的。

這也創造了犯錯的空間，因為使用者在執行像 pip 這樣的安裝程式前，需要記得啟用虛擬環境，或對安裝程式進行報錯配置。在某些 Linux 發行版上，忘記這樣做可能會導致安裝程式修改作業系統所擁有的檔案（對於選擇按照 PEP 668 標記其環境的發行版，此問題已得到部分緩解）。

原理

將像 pip 這樣的安裝程式預設行為更改為要求啟用虛擬環境將會：

• 使新使用者更容易開始使用 Python（因為有一致的體驗，且虛擬環境被理解為必須使用的東西）
• 預設降低所有使用者發生意外安裝問題的可能性（透過在未使用虛擬環境時明確發出警示）。

建立一個將虛擬環境放在目錄樹中名為 .venv 的目錄下的慣例，消除了常見流程中的一個決策點，並在生態系統中建立了一個明確的規範。

規範

回溯相容性

此 PEP 與使用者在虛擬環境之外使用安裝程式的工作流程不回溯相容。此類使用者將收到錯誤訊息，並需要：

• 明確選擇在虛擬環境之外執行安裝程式，或
• 建立並使用虛擬環境

已經在使用虛擬環境的使用者將不受此變更的影響。

工作流程工具（在底層為使用者管理虛擬環境的工具）不應受到影響，因為它們應該已經在使用虛擬環境來執行安裝程式。

安全性影響

此 PEP 沒有引入任何新的安全隱患。

如何教學

此 PEP 要求新使用者在開始使用 Python 套件之前必須建立並使用虛擬環境。然而，這是一項最佳實踐，誠如 Python 套件使用者指南中「如何安裝 Python 套件的基礎知識」一節所展示的，該節在討論使用 pip 之前就解釋了什麼是虛擬環境及其用途。

參考實作

此 PEP 沒有參考實作。然而，提議的行為在 pip 中已大致實作，且可以透過將環境變數 PIP_REQUIRE_VENV 設定為 1 來啟用。（若不設定，則為提議的選擇加入行為，即安裝時不要求虛擬環境。）

實作筆記

def is_virtual_environment():
    return sys.base_prefix != sys.prefix or hasattr(sys, "real_prefix")

否決的想法

待決問題

無。

版權

本文件已進入公有領域或遵循 CC0-1.0-Universal 授權，以較寬鬆者為準。