haskell - 发布 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

这是一个棘手的问题，因为社区中对最佳实践有不同的看法，并且在易于确定界限和提供与可能的依赖版本的最大兼容性之间存在权衡。在我看来，基本上可以采用三种方法:

查看您当前使用的依赖项的版本，例如safe-0.3.15 .假设软件包遵循 PVP 并且不会在 0.4 版本之前发布重大更改，并添加以下内容:safe >= 0.3.15 && < 0.4

以上内容很好，但限制了许多潜在有效的构建计划。您可以花时间针对其他版本的依赖项进行测试。例如，如果您针对大约 0.2.12 和 0.4.3 进行测试，并且它们似乎都有效，您可能需要扩展为 safe >= 0.2.12 && < 0.5。 .

注意 :出现的一个常见错误是，在您的软件包的 future 版本中，您忘记检查与旧版本的兼容性，结果您使用的是安全 0.4.1 中引入的新功能，使旧的界限无效的。不幸的是，没有多少自动化工具可以检查这一点。

忘记这一切:根本没有版本限制，并让包的消费者负责确保构建计划中的兼容性。这样做的缺点是可能会创建无效的构建计划，但好处是您的界限不会消除潜在的良好计划。 (这基本上是误报与误报的权衡。)

Stackage project运行夜间构建，通常可以让您知道您的包何时被新版本的依赖项破坏，并通过提供已知有效的预构建快照使用户更容易使用您的包。这对案例 (3) 尤其有帮助，对于 (2) 中的宽松下限也有一点帮助。

您可能还需要考虑使用 Travis 配置来针对旧 Stackage 快照进行测试，例如https://github.com/commercialhaskell/stack/blob/master/doc/travis-complex.yml