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社区，是他们让这个项目在如此短的时间内取得了如此巨大的成功。没有他们的帮助，这是不可能的。