Question

运行paket.dependencies时生成的dotnet new fake示例文件目前看起来像：

// [ FAKE GROUP ]
group Build
    source https://api.nuget.org/v3/index.json
    nuget Fake.DotNet.Cli
    nuget Fake.IO.FileSystem
    nuget Fake.Core.Target

我了解如何使用依赖项组来解决版本冲突，但是似乎没有必要在实际的版本冲突情况出现之前引入它们。

此处 Build 组的含义是什么？为什么不将三个依赖项放在 Main 默认组下？相同的反映适用于Paket documentation example中的 Test 组。

在没有版本冲突的情况下，能否详细说明将组中的依赖项分离的原因？也许可以解释一下 Build 和 Test 组背后的基本原理？

Answer 1

我已经基本介绍了针对FAKE 5的拆分：

原因是，一组依赖项在BUILD时（即运行构建脚本时）使用，而一组依赖项则在项目RUN时使用。这两个有一组不同的依赖关系是完全有效的。

请考虑以下情形：在构建过程中使用FSharp.Formatting（FSF，降价解析器）项目来生成API文档，并在项目中使用来生成网站。现在，您想通过更新FSF来更新API文档，但是由于兼容性原因，您不能在项目中升级FSF。通过将BUILD和RUN-TIME分开，这不是问题，您可以将它们视为不同版本中的“不同”依赖项。

我想看看这种类似于节点如何将dependencies和dev-dependencies分开的方法

关于“运行”和“测试”之间的区别：就我个人而言，我不是一个狂热的粉丝。我可以看到人们想如何分离他们的依赖关系，但是paket当前并不“真正”支持该方案，您确实会遇到这种方法的问题。我目前的建议是不要在“运行”和“测试”之间分割，而应将它们分组管理。

要在RUN和TEST程序包之间正确划分，将需要一项新功能来引用另一个组：

group Run source https://api.nuget.org/v3/index.json nuget MyDep1 group Test reference_group Run source https://api.nuget.org/v3/index.json nuget MyRunner1

类似于外部锁定文件功能：https://github.com/fsprojects/Paket/pull/3062#issuecomment-367658114

Paket依赖组不仅仅是解决版本冲突的一种方法吗？

1 个答案: