【问题标题】：Why does Paket need three files to support dependency management?为什么 Paket 需要三个文件来支持依赖管理？
【发布时间】：2017-08-19 14:17:36
【问题描述】：
我是一名使用过 Maven 和 Gradle 的 Java 开发人员，现在开始接触 .NET 并试图了解 Paket。据我了解，Paket 有三个不同的文件支持 .NET 解决方案的依赖管理：
- 一个根 paket.dependencies 文件，您可以在其中列出您的直接依赖项和版本。
- 一个项目特定的 paket.references 文件，其中列出了您已经在 paket.dependencies 中列出的依赖项的子集。
- 一个 paket.lock 自动生成的文件，其中列出了所有直接和传递依赖项及其版本。
使用 Maven 和 Gradle，我习惯于在一个文件中指定我的依赖项。我可以指定确切的版本，并确保后续下载的依赖项是相同的。为什么Paket需要三个文件？我希望每个项目中的 paket.references 文件就足够了。在 .NET 世界中，我不知道需要这三个文件的依赖项的管理方式是否存在一些问题或怪癖？
【问题讨论】：
-
如果您熟悉单文件解决方案并且它适用于您的用例，那么开始使用NuGet 会更容易。 NuGet 是 MS 提供的默认包管理器。 Paket 让您做更多事情，例如保证一致的依赖关系恢复，保证您的解决方案中的项目使用相同版本的包并且您在运行时不会感到意外，从 GitHub 恢复文件作为依赖项等等。
标签：
.net
maven
build
dependency-management
paket
【解决方案1】：
- 根 paket.dependencies 文件 -- 您可以在此文件中对依赖项进行分组，从而访问同一依赖项的不同版本。
- 项目特定的 paket.references 文件 -- 在 paket.dependencies 中为单个项目定义的依赖项。可以选择引用一组 paket.dependencies 文件中的依赖项。
- 一个 paket.lock 自动生成的文件 -- 您的构建将使用此文件，而不是其他文件，以确保引用透明性。您可能会或可能不会在 paket.dependencies 中包含指定版本的说明。 paket.lock 文件每次都将构建锁定到相同的特定版本。您必须有意采取某种措施，通常使用 paket update 或 paket install 来更新您希望下一个构建使用的版本。
【解决方案2】：
问题不在于 .NET 中的依赖管理有什么独特之处。在依赖管理方面，Gradle（尽管如此出色）和 Maven 缺少一些关键特性。
-
每个项目分别指定每个依赖项的版本。考虑这些依赖关系：
- 项目 A：X 1.0
- 项目 B：X 2.0，项目 A
这两个项目将使用两个不同版本的依赖项 X 构建，即使它们最终注定要用于同一个应用程序。更糟糕的是，每个项目的测试将使用不同版本的依赖 X 运行。
Paket 通过指定哪个项目需要依赖项（'paket.references'）以及应该单独使用哪个版本的依赖项（'paket.dependencies'）来解决这个问题。这样可以保证使用相同依赖项的多个项目使用相同的版本。
由于 Gradle 非常灵活，有多种方法可以确保在不同项目中使用相同版本声明依赖项。但它们都不是非常直观，也没有标准的方法。
- 虽然在 Maven 和 Gradle 中，您可以指定直接依赖项的确切版本，但传递依赖项的解析是在运行时完成的，并且取决于项目外部的因素（例如包源中可用的依赖项版本）。这可能会导致在不同时间或在使用不同依赖项的不同机器上对同一源进行两次构建。
这是每个平台上依赖管理的常见问题，标准的解决方案是一个锁文件（'paket.lock'），它保存了依赖解析的结果以供将来构建使用。
多年来，Gradle 没有内置对锁定文件的支持，尽管 Netflix 提供了一个添加锁定功能的 Nebula 插件。最近 Gradle 增加了对锁定文件的内置支持。