一如既往，這是一種權衡，我在標準和可預測性方面犯了錯誤。我敏銳地意識到，尤其是對於單一用途的 Python 容器，例如Python：。– 透過全域安裝所有內容來實現多階段建置是很流行的複製

超過站點包從Python安裝的內部，或設定Python是使用者群組環境變數類似的東西/應用程式，並使用pip安裝--用戶而不是點安裝， 進而複製超過那。所有這些的前提是它更簡單且一層隔離就足夠了。我並不質疑一層隔離的充分性，但多年來，我發現在生產中，在談論簡單性時需要記住的不僅僅是一個面向。作為一個總體主題，我的目標是不是

盲目地遵循一些“最佳實踐”，這會增加可疑回報的複雜性，因為一位大型技術開發倡導者在一次會議上這麼說。

但我花了很多時間思考次要效應我所做的事情。對我來說，複雜性並不在於我必須按多少個鍵，而是在於推理我正在做的事情的後果有多困難。因此，以下是我仍然使用虛擬環境併計劃在未來這樣做的不完整原因清單：

可預測性和熟悉度

它們的結構定義良好，旨在容納單一 Python 應用程式。

我喜歡它們的目錄層次結構，其中包括

垃圾桶,庫， 和分享目錄，使其成為預設自包含應用程式的絕佳“容器”。它需要存儲輔助文件，包括附加文件中的奇怪配置文件ETC目錄。所有這些使它們非常適合放入一些東西/選擇/應用程式或者/應用程式。

是的，與十年前不同，您不必再將應用程式與系統 Python 隔離。但保留你的位於隔離的、定義明確的位置和結構中的程式碼本身就有價值。我負責數十項服務，因此我很感激

一致性知道我正在部署的所有內容都在/應用程式，如果它是一個 Python 應用程序，我知道它是一個虛擬環境，如果我運行/應用程式/bin/python，我獲得了虛擬環境的 Python，並準備好導入和運行我的應用程式。標準和溝通

所有這些一致性使得

團隊內部與團隊之間的溝通更輕鬆。如果我說/記錄部署工件是虛擬環境，每個人都知道這意味著什麼。如果他們不這樣做，互聯網上就會充滿文檔，其中包括官方一。就像當黑色的讓我們停止思考和爭論程式碼風格，並將這些精神資源釋放到更重要的事情上¹。這就是標準的最終價值，即使人們不喜歡標準的一切。

虛擬環境已經Python 的核心功能12年也是自 2000 年代中期以來 Python 社群的核心概念。這是我們最接近的東西Python 中封閉的、標準化的、易於理解的應用程式建構工件。這是一個延伸的類比，但我認為它們是在編譯語言中連結動態二進位檔案的結果。

你可以使用它們本地，您可以使用部署它們發行版包，你可以使用 Docker 容器部署它們。它是好的在開發和生產中使用相同的工具和原語。這意味著您了解自己的工具並且需要記住的事情更少。因此，使用不同的方法來部署應用程式應該能帶來實際的好處。

導入複雜性崩潰

這是虛擬環境的普遍優點（無論是在本地還是在 Docker 中），您可以縮小相關搜尋路徑Python 會在其中尋找要匯入的程式碼²。運行Python在透過隔離模式-我 將進一步縮小範圍。

所以，如果你 a) 永遠不要全域安裝任何東西³,和你 b) 使用Python來自虛擬環境的二進位文件儘管透過它-我， 你知道標準庫中沒有的所有內容必須處於虛擬環境。這使得 Python 的導入行為更加有效可預測的調試導入問題不再是謀殺之謎。

這讓我們想到…

可以安全地忽略的獎勵點，但我需要把它說出來

地獄沒有像我所感受的那樣的憤怒pip安裝--用戶。這是一個極具吸引力的麻煩，對 Python 的不良打包聲譽造成了極大的傷害。

它主要用於掩蓋操縱系統帶來的更糟糕的影響站點包目錄 – 損壞 Python 安裝最常見的原因。所有這些都是為了啟用用戶本地安裝⁴，這從一開始就是一個壞主意。從這個意義上來說，新專案管理生態系統及其專案目錄本地優先包裝遠遠領先於我們，停留在我們古老的、懶惰的方式上。

最後，透過添加以下內容，Python 安裝的推理變得更加複雜其他移動部分。如果每次有人因為用戶本地 Python 包中的奇怪內容而在錯誤追蹤器上對我大喊大叫時，我都會得到一毛錢，那麼我就不必這樣做了請求贊助。就如我所愛的那樣專案資料管理，我每天都感謝克蘇魯PEP 582 /__pypackages__被拒絕，因為它會添加其他混亂的向量。項目本地標準化.venv是明確正確的舉動，即使我喜歡將我的虛擬環境儲存在一個中心位置。

最後：就像，……到底為什麼？

您到底想在這裡解決什麼問題？它不是一個額外的工具或一個額外的概念 - 或者它就存在於標準函式庫，或者您正在使用紫外線已經。和紫外線，創建虛擬環境並不比創建虛擬環境花費更長的時間目錄。他們可能是輕微地更大，但它們真的很重要嗎？透過避免使用一種標準方法將 Python 專案及其所有相依性隔離到易於處理的目錄中，您不會使任何事情變得更簡單。

我想知道對虛擬環境的抵制有多少不是出於技術原因，而是根源於每次 Python 更新都會破壞它們Debian 對 Python 安裝的煩人分拆讓它們使用起來很痛苦。

我希望紫外線— 便利性和速度將改變大眾的看法。

結語

我在文章開頭描述的捷徑依賴以下假設站點包— 位置和便攜性。他們引入了複雜性，例如使用pip安裝--用戶（這在 Docker 中在語義上很奇怪，並且從來不打算用於這樣的事情）並且與您在開發中使用的工具和範例相比，可能需要不熟悉的工具和範例。 -----ª

但我並不是想說服你做任何事。我確實意識到我的一些原因是在無形的~氛圍~方面。如果您在這些捷徑的範圍內並且對權衡感到滿意，那麼您可以自由地做您想做的事情。但我希望我已經向你表明，它確實做一般來說，在 Docker 中使用虛擬環境是否有意義 – 是否有意義你，是為了你來決定。我只是厭倦了每次都為自己辯護，所以我在這裡一勞永逸地闡述我的觀點。

如果經歷了這一切之後你是仍然如果對 Python 和 Docker 感興趣，我建議從生產就緒的 Docker 容器紫外線，這是我如何盡快為 Python 應用程式建立 Docker 容器的動態文件。

附：我簡直不敢相信我竟然在我可敬的人十週年紀念日那天發表了這篇文章– virtualenv 還活著！！很多事情都變得更好了，但虛擬環境仍在不斷進步。