在发布Haskell库时,如何确定合理的包依赖性边界？

Question

在Hackage上发布库时,如何确定依赖项的合理边界？

这是一个非常简短的问题 - 不确定我能提供哪些其他信息.

根据是使用堆栈还是使用cabal来了解这是否有所不同也是有帮助的.

---

基本上我的问题涉及当前设置为的cabal约束:

library
  hs-source-dirs: src
  default-language: Haskell2010
  exposed-modules: Data.ByteUnits
  build-depends:       base >=4.9 && <4.10
                       , safe == 0.3.15

我不认为这==是个好主意.

Answer 1

这是一个棘手的问题,因为社区中对最佳实践有不同的意见,并且在计算边界的容易性和提供与可能的依赖版本的最大兼容性之间存在权衡.在我看来,基本上有三种方法可以采取:

1. 查看您当前使用的依赖项的版本,例如safe-0.3.15.假设软件包遵循PVP并且不会在版本0.4之前发布重大更改,并添加以下内容:safe >= 0.3.15 && < 0.4
2. 以上是很好的,但限制了许多潜在有效的构建计划.您可以花时间测试其他版本的依赖项.例如,如果你测试大约0.2.12和0.4.3并且它们似乎都有效,你可能想要扩展到safe >= 0.2.12 && < 0.5.
   • 注意:一个常见的错误是,在您的软件包的未来版本中,您忘记检查与旧版本的兼容性,并且事实证明您正在使用在safe-0.4.1中引入的新功能,边界无效.遗憾的是,自动化工具检查这一点并不多.
3. 忘记所有内容:根本没有版本限制,并使包的使用者负责确保构建计划中的兼容性.这有一个缺点,即可以创建无效的构建计划,但是你的界限不会消除潜在好的构建计划的好处.(这基本上是假阳性与假阴性权衡.)

该Stackage项目运行每晚构建,可以经常让你知道当你的包被依赖的新版本打破了,使得用户更容易通过提供已知的工作预先建立快照消耗你的包.这尤其有助于案例(3),以及(2)中松散下界的一点点.

您可能还需要考虑使用特拉维斯配置迎战老Stackage快照的测试,如https://github.com/commercialhaskell/stack/blob/master/doc/travis-complex.yml

Answer 2

我假设你知道Haskell包版本控制策略(PVP).这提供了一些指导,隐含在它分配给版本的前三个组件("ABC")的含义以及对Cabal版本范围的一些明确建议.

粗略地说,未来的版本中使用相同的"AB"会不会推出任何重大的变动(包括实行可能改变其他代码的行为孤儿情况下),但可能会增加了新的绑定,类型等提供您仅使用合格导入或显式导入列表:

import qualified Something as S
import Something (foo, bar)

你可以安全地写一个表单的依赖:

something >= 1.2.0 && < 1.6

假设您已经1.2.0通过测试1.5.6,并且您确信它将继续与所有未来1.5.x(非破坏性变化)一起运行,但可以想象会打破未来1.6.

如果您导入了一个不合格的软件包(如果您要重新导出其大部分API,那么您很可能会这样做),您需要一个变体:

the-package >= 1.2.0 && < 1.5.4   -- tested up to 1.5.3 API
the-package >= 1.5.3 && < 1.5.4   -- actually, this API precisely

如果您定义孤立实例,还有一个警告(请参阅PVP).

最后,在导入一些简单,稳定的软件包时,您只导入了最明显稳定的组件,您可能会假设:

the-package >= 1.2.0 && < 2

会非常安全的.

查看Cabal文件中的大型,复杂,编写良好的软件包可能会让您了解在实践中所做的工作.lens例如,该包广泛使用了表单的依赖关系:

array >= 0.3.0.2 && < 0.6

但有偶尔的依赖,如:

free >= 4 && < 6

(在许多情况下,这些更广泛的依赖关系是由同一作者编写的包,他显然可以确保他不会破坏自己的包,所以可能会更加松懈.)