为什么Paket需要三个文件来支持依赖管理？

Question

我是一个习惯于Maven和Gradle的Java开发人员，现在进入.NET并试图理解Paket。据我理解，Paket有三个不同的文件支持.NET解决方案的依赖管理：

1. 列出直接依赖项和版本的根paket.dependencies文件。
2. 一个特定于项目的paket.references文件，其中列出了已经在paket.dependencies中列出的依赖项的子集。
3. paket.lock自动生成的文件，它列出了所有直接和传递的依赖项及其版本。

对于Maven和Gradle，我习惯于在一个文件中指定我的依赖项。我可以指定确切的版本，并确保随后的依赖项下载将是相同的。为什么Paket需要三个文件？我希望每个项目中都有一个paket.references文件就足够了。在.NET世界中，在如何管理依赖关系方面有什么问题或怪癖吗?我不知道这三个文件是需要的吗？

Answer 1

1. 根paket.dependencies文件--您可以将该文件中的依赖项分组，从而访问相同依赖项的不同版本。
2. 特定于项目的paket.references文件--在paket.dependencies中为单个项目定义的依赖项。可选地引用paket.dependencies文件组中的依赖项。
3. 一个paket.lock自动生成的文件--您的构建将在这个文件上工作，而不是其他文件，以确保引用的透明性。您可能已经在paket.dependencies中包含了版本指定说明，也可能没有。paket.lock文件每次都将构建成相同的特定版本。您必须有意识地采取某种操作，通常使用paket或paket来更新您希望下一个版本使用的版本。

Answer 2

问题不在于.NET中的依赖管理有什么独特之处，而在于Gradle (尽管它很棒)和Maven在依赖性管理方面缺少了一些关键特性。

1. 每个项目分别指定每个依赖项的版本。考虑这些依赖关系：

- Project A: X 1.0
- Project B: X 2.0, Project A

​

这两个项目将使用两个不同版本的依赖X构建，尽管它们最终将用于同一个应用程序。更糟糕的是，每个项目的测试将以不同版本的依赖X运行。

Paket通过指定哪个项目需要依赖项('paket.references')和应该分别使用哪个版本的依赖项('paket.dependencies')来解决这个问题。这样，可以保证使用相同依赖项的多个项目使用相同的版本。

因为Gradle非常灵活，所以有多种方法可以确保在不同的项目中用相同的版本声明依赖关系。但是没有一个是非常直观的，也没有标准的方法。

1. 虽然在Maven和Gradle中，您可以指定直接依赖项的确切版本，但传递依赖项的解析是在运行时完成的，并且取决于项目之外的因素(例如从包源可以获得哪些依赖项版本)。这可能导致在不同的时间或在不同的机器上使用不同的依赖关系生成相同源的两个版本。

这是每个平台上依赖关系管理的一个常见问题，标准的解决方案是一个锁文件('paket.lock')，它保存了在未来构建中使用的依赖解决方案的结果。

多年来，Gradle没有内置的锁文件支持，尽管Netflix的Nebula插件增加了锁定功能。最近，Gradle增加了对锁文件的内置支持。