hackage 包依赖项和面向未来的库答案

【问题标题】：hackage package dependencies and future-proof librarieshackage 包依赖项和面向未来的库
【发布时间】：2010-05-12 23:34:24
【问题描述】：

在 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 转换器和类）

如果我不设置限制 - 我的包裹可能会因“变压器”的变化而损坏
如果我确实设置了限制 - 使用“转换器”但使用更新版本的用户将无法将 lift 和 liftIO 与 ListT 一起使用，因为它只是这些类的一个实例变压器-0.2.x

我猜应用程序应该总是设置上限，这样它们就不会中断，所以这个问题只与库有关：

我是否应该对依赖项使用版本上限？

【问题讨论】：

【解决方案1】：

有一个明确的 policy 推荐上限 - 请参阅第 3 节（“Cabal 中的依赖项”）。其他答案为这项政策提供了一些进一步的理由。

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

【讨论】：

【解决方案2】：

考虑故障模式：

输入上限。

【讨论】：

有了上限，cabal 不会因为不满意的构建依赖而喋喋不休，我对其进行了测试并打印“警告：此包间接依赖于同一包的多个版本。这很可能会导致编译失败。”。那么客户包可能会因为缺少实例而无法编译
@yairchu：这是否意味着你导入到你的包中的一个包依赖于transformers，但是有不同的版本约束？
@jberryman：完全正确。我的测试包依赖于 List 依赖于变形金刚 >= 0.2.0 和 MaybeT-transformers 依赖于变形金刚 0.1.*
@yairchu, @jberryman：对阴谋集团不利！这有点咩咩，但还不够。你应该给它某种-force 选项才能让它继续。我会提交错误报告。
我认为这只是一个警告而不是错误很好。即使使用了同一个包的多个版本，也有很大的机会可以正常工作。这允许更多的互操作性，同时推动开发人员通过警告更新他们的代码。

【解决方案3】：

IMO 为接受的版本号设置上限是正确的做法。鉴于 Hackage 使用的版本号的语义，当然不能保证您的包可以使用，在这种情况下，变形金刚 0.3.0。

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

【讨论】：