基於完整揭露原則：我是 Pipenv 三位目前的主要維護者，並同時維護其部份依賴。Pipenv 與 PyPA 並沒有嚴格組織，也不對維護者組成有任何約束，因此以下是我個人的觀點，無法代表 Python 官方意見。然而，我認為我的看法與 Python 核心社群的普遍共識一致。「 Pipenv 解決什麼問題」這個問題容易讓人落入邏輯誤區，因為 Pipenv 本質上包含了兩個不直接相關的部份：Pipfile 標準，以及 Virtualenv 操作。Pipenv 在兩個部份都試圖解決現有方案的問題，但是必須分開來看，才能正確評價它。

Pipfile 的目標是取代現在慣常使用的 requirements.txt 格式，並引入 lock file 概念（或者叫做 shrinkwrap ）。這和 pip freeze 最大的差異是，lock file 是一個理論上的依賴視圖，而 pip freeze 是產生實際上的依賴視圖。當你使用 pip freeze 時，只是單純將已經安裝的套件狀況「倒」出來。當你觸發 locking 行為時，則是會直接取用套件的 metadata，直接建立套件的依賴結果。這在理論上是個沒有副作用的行為（當然實際上套件在編譯期有什麼副作用是完全未知的，這沒有辦法），所以只要依賴本身沒有改變（例如沒有更新），每次 locking 的行為應該完全相同。這在依賴解析上是重要的特性，有興趣的人可以自行研究，這裡不贅述。

上面的說法可能會讓你認為 Pipfile 的進步點在於一個更好的依賴解析格式與行為，但其實不是如此。它提供的是依賴解析這件事情「本身」——因為這個概念在 pip 中根本不存在。考慮以下的狀況：你的專案使用了套件 A 套件，它依賴於套件 B 的 2.x 系列。你的 requirements.txt 可能會長這樣：

A==1.0
B==2.5.1

現在你想要實作新功能，而加入套件 C，而它依賴 B 套件 3.0 的 API。在使用 pip 的狀況下，你會 pip install C。由於 pip 本身並沒有依賴解析功能，它只知道要安裝 C，以及其依賴 B 3.0，於是你的 freeze 結果變成這樣：

A==1.0
B==3.0.0
C==1.0

這時候 A 很可能無法使用，而你也已經失去了前一個狀態，必須重新建立你的開發環境。但是更可能的是，如果你沒有完整的測試機制，說不定完全不會發現這件事情，直到有人抱怨。

另一方面，由於 Pipfile 擁有獨立的解析步驟，且不需要先將套件實際安裝至環境中，當你將 C 加入 Pipfile 時，locking 就會直接告知你這個依賴無法被解析，防止後面的所有問題。並且由於它只有在解析成功時，才會進行安裝，你只要把 C 從 Pipfile 移除，即可回到原本的專案狀態。

基於同樣的理由，Pipfile 同時也有一些其他好處。如果你有平台專屬的依賴，例如 Windows 使用 X 套件，在 Mac 使用 Y，然後寫一個抽象層之類的需求，pip freeze 基本無法處理。Pipfile 因為不需要把套件本身裝到環境中，就可以處理這個狀況。

在 Pipfile 之前，也有其他類似功用的專案，只是沒有提出全新的格式，而是沿用 requirements.txt 。piptools 是一個比較有名的實例。不過 Pipfile 的 TOML 格式與 lock file 的 JSON 格式比起基於行的純文字 requirements.txt 遠遠更有表達能力，能夠處理更廣泛的使用情境。

回到 Pipenv，在虛擬環境的使用上，它的創新度就遠沒有 Pipfile 格式那麼高，只是一個 virtualenv 的殼，唯一比較值得一提的，只有 run 與 shell 這兩個指令。Shell 前面有人已經提到，比起 activate 要方便一些，因為後者是直接修改你現有的 shell 環境，而 shell 是直接啟動一個 shell 子程序，所以跑起來更乾淨，也不容易出錯。不過這年頭 terminal emulator 滿街跑，這也有很多其他 workaround 做法，shell 充其量就是推廣這樣的 best practice 讓更多人知道。Run 也是差不多，其實就是自動幫你 active-執行指令-deactivate。非常方便，但沒有特別解決什麼問題。

如果你問 Pipenv 解決了什麼問題，對我而言，Pipfile 格式與它提供的 locking 才是重點，虛擬環境管理我自己寫一個也不費什麼力氣（我加入 Pipenv 之前就寫過，現在還是有自己寫），其實沒什麼。但是對 Pipenv 使用者而言，每天用到的都是虛擬環境的介面，套件管理根本用不到個幾次，更難注意到它的技術細節差異，所以單純看它的虛擬環境指令，覺得好像可有可無也是合情合理，我們維護者也都很清楚，所以我們最近（大約是從今年 PyCon US 起，到現在大約一個月）努力的方向，就是盡可能把 Pipenv 的各個組件拆分成獨立的套件，並鼓勵大家根據這些套件建構自己的工具，讓這些技術能夠正確地被評價。

Pipenv 的初始作者是 Kenneth Reitz，我想大家都很清楚。Kenneth 最突出的技能，是為一個工作流程設計流暢、實用、完整的介面，如果你有密切關注他過往的專案，例如 Requests 與 Records，應該能夠很明顯察覺。然而在設計流暢介面時，有時候就免不了犧牲技術上的純粹性：Requests 的 json() 函式與 Records 的 Pandas 整合都是十分明顯的例子。在這兩個專案中，HTTP 與 SQL 基本都是應用相當成熟的應用，所以大家也比較能夠準確評價這些功能的，以及函式庫的定位，但套件管理在 Python 社群，甚至整個程式社群中，就不是那麼普遍的知識，因此當你把很多個技術混在一起時，大家就很難準確評價最終成果。這有點令人遺憾，不過也是我們接下來最重要的努力目標。希望這樣的解釋能夠讓大家更理解套件管理與依賴解析，進而能夠理解，甚至協助建立 Pipenv 的正確定位。