Paket：一個面向.NET的包管理器

Steffen Forkmann：雖然我們確實非常喜歡使用NuGet包，而且也為其生態系統做貢獻，但在一些特殊的情況下，我們還是感覺很痛苦。大多數問題都是源于NuGet“ 它只是一個Visual Studio宏 ”的理念。這意味著，nuget.exe并沒有被視為一個真正的依賴管理器，但作為一個宏，它允許開發人員下載包并Visual Studio項目內部引用它們。對于許多專業軟件開發項目，這種隱藏依賴的理念帶來了許多痛苦。加之nuget.exe存儲包的路徑里會帶有版本號，而且沒有全局概覽，除非是在最簡單的項目中，否則很快就會變得難以管理。

在我們開始Paket項目的時候，我們已經仔細進行過一些關于修改NuGet模型的討論，但NuGet的團隊明確表示，這不是他們想要的方式。由于Paket大多數新增功能都是破壞性的，他們無意將這些更改引入nuget.exe。

所以，為了解決我們自己的依賴管理問題，Alexander Gross和我就開始創建一個新的項目。項目的范圍只是取代nuget.exe，也就是取代NuGet的客戶端。另外，我們還制定了以下項目原則：

• 可以融入現有的NuGet生態系統
• 使用最少的工具（純文本文件）做事
• 適用于所有平臺
• 一切都是自動化的
• 創建一個優秀的社區

SF：Paket使用paket.dependencies文件指定項目依賴。通常僅指定直接依賴，而且所允許的包的版本范圍常常很廣。在“paket install”的過程中，Paket需要指定特定包的具體版本，以及它們的傳遞性依賴。然后，這些版本會保存到paket.lock文件。

為了指定具體的版本，Paket需要解決如下約束滿足問題：對于paket.dependencies文件中的每一個包以及它們所有的傳遞性依賴，均選擇最新的版本，這樣，所有的版本約束就都得到了滿足。

對于這個問題，通常存在不止一個解決方案，而解析器會選擇它找到的第一個方案。Paket的網站上有一篇文章 更詳細地解釋了解析過程 。

如果解析器無法找到一個有效的解決方案，那么它需要向用戶報告一個錯誤。由于搜索樹可以非常大，而且可能包含許多不同種類的失敗，所以它只會報告最后一個它無法解析的沖突，以及一些有關這個沖突的來源信息。

與nuget.exe不同，在整個解決方案中，相同的包，Paket只允許用戶使用一個版本。因此，用戶不會無意中因為從不同的項目中引用同一個包的不同版本而引入版本沖突。如果實在需要同一個包的不同版本，那么可以通過 依賴組 來實現。

SF：是的，Paket基本上支持所有的.NET語言——甚至是像Nemerle那樣的東西。我們的大多數用戶都是C#企業型公司，但由于我們沒有跟蹤我們的用戶，所以我們沒有任何相關的統計數據。

SF：目前，我們正致力于Paket 3.0的開發，它會帶來一項重要的新特性。基本的思路是，用戶可以在paket.dependencies文件中引用一個Git庫，Paket會為用戶克隆和構建項目。如果構建生成了NuGet包，那么用戶可以把它們作為額外的包來源。

目前要求最多的特性是支持CoreCLR/DNX項目，但我們需要為此對project.json模型做些修改。遺憾的是，我們現在還沒有想出一個滿意的方案，但我們希望能夠同微軟的團隊一起來解決這個問題。

SF：我想謝謝所有的貢獻者以及整個Paket社區，是他們讓這個項目在如此短的時間內取得了如此巨大的成功。沒有他們的幫助，這是不可能的。