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



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

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

使用 Maven 和 Gradle,我习惯于在一个文件中指定我的依赖项。 我可以指定确切的版本,并确保依赖项的后续下载将是相同的。 为什么Paket需要三个文件? 我希望每个项目中的paket.references文件就足够了。 .NET 世界中是否存在一些问题或怪癖,即如何管理依赖项,以至于我不知道需要这三个文件?

  1. 根 paket.dependencies 文件 -- 您可以在此文件中对依赖项进行分组,从而访问同一依赖项的不同版本。
  2. 项目特定的 paket.reference 文件 -- 在单个项目的 paket.dependencies 中定义的依赖项。(可选)引用一组 paket.dependencies 文件中的依赖项。
  3. paket.lock 自动生成的文件 -- 您的构建将使用此文件而不是其他文件,以确保引用透明度。您可能已经(也可能没有)在 paket.dependencies 中包含版本指定指令。paket.lock 文件每次都会将构建锁定到相同的特定版本。您必须有意采取某种操作,通常使用 paket 更新或 paket install 来更新您希望下一个版本使用的版本。

问题不在于 .NET 中的依赖项管理有任何独特之处。而是Gradle(尽管它很棒)和Maven在依赖关系管理方面缺少一些关键功能。

每个
  1. 项目分别指定每个依赖项的版本。请考虑以下依赖项:

    • 项目 A: X 1.0
    • 项目
    • B:X 2.0,项目 A

这两个项目将使用两个不同版本的依赖项 X 进行生成,即使它们最终发往同一个应用程序。可以说更糟糕的是,每个项目的测试将使用不同版本的依赖项 X 运行。

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

由于 Gradle 非常灵活,因此有多种方法可以确保在不同项目中使用相同的版本声明依赖项。但是它们都不是非常直观,也没有标准的方法。

  1. 虽然在 Maven 和 Gradle 中您可以指定直接依赖项的确切版本,但传递依赖项的解析是在运行时完成的,并且取决于项目外部的因素(例如包源中可用的依赖项版本)。这可能会导致同一源在不同时间或使用不同依赖项的不同计算机上的两个生成。

这是每个平台上依赖项管理的常见问题,标准解决方案是锁定文件("paket.lock"),它保存依赖项解析的结果以在将来的构建中使用。

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

相关内容

  • 没有找到相关文章

最新更新