在 cabal 文件的依赖项部分:

Build-Depends: base >= 3 && < 5, transformers >= 0.2.0

我应该做类似的事情吗

Build-Depends: base >= 3 && < 5, transformers >= 0.2.0 && < 0.3.0

(对我依赖的包的版本设置上限)

或不?

我将使用一个真实的例子:我在 Hackage 上的“List”包(列出 monad 转换器和类)

  • 如果我不设置限制 - 我的包可能会因“变形金刚”的更改而损坏
  • 如果我确实设置了限制 - 使用“变压器”但使用其较新版本的用户将无法使用 liftliftIOListT 因为它只是这些 Transformers-0.2.x 类的一个实例

我想应用程序应该始终设置上限,以便它们永远不会中断,所以这个问题仅与库有关:

我是否应该使用依赖项的版本上限?

有帮助吗?

解决方案

有一个明确的 政策 推荐上限 - 特别参见第 3 节(“Cabal 中的依赖关系”)。其他答案为这项政策提供了一些进一步的理由。

简而言之 - 上限应为 < A.(B+1) 其中 A 和 B 是当前版本的第一个元素 (A.B.C...)。这是因为增加 A.B 应该意味着该版本破坏了旧的 API。

其他提示

考虑一下故障模式:

  • 有了上限,要么你的包构建,要么阴谋集团抱怨不满足的构建依赖关系。责任归属明确。

  • 如果没有上限,客户拥有最新版本的变压器,并且不向后兼容。您的软件无法构建;GHC 抱怨你的代码无法编译。你的软件看起来很劣质。

放入上限。

IMO 对接受的版本号设置上限是正确的做法。鉴于 Hackage 使用的版本号语义,当然不能保证您的包能够与 Transformers 0.3.0 一起使用(在本例中)。

不过,我还没有看到任何关于此问题的真正讨论,并且除了基本包之外,似乎没有一般建议使用上限。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top