分发Haskell应用程序并进行更新的最佳实践

 

TL;博士

大约一周前，我为我的第一个非平凡的Haskell项目发布了0.1.0.0包。 我希望可执行文件易于安装和升级，即使对于非Haskellers也是如此。 在README中，我建议使用cabal install 。 这是一个错误吗？

上下文

我听说过“Cabal hell”，但并没有意识到，即使我保守地没有实际更改.cabal文件中的任何版本依赖关系，用户也无法升级全局安装的软件包副本。 最后，我走下了一个深深的兔子洞，试图从0.1.0.0更新到0.2.0.0。 它警告我关于中断依赖关系，我尝试了各种咒语来强制升级或重置我的本地状态，并且因为系统太麻烦而不得不重新安装ghc和cabal-install Brew软件包（这是在macOS上）让一切回到我可以安装并重新运行的状态。

备择方案：

  • stack install ：我已经在使用Stack来管理本地开发环境，但对于独立安装，它似乎也能很好地工作，只要您先安装了堆栈。 （只需要适当地设置你的$PATH 。）
  • 分发一个预编译的二进制文件：对于最终用户来说会很好，很容易，但至少在OS X上，我需要担心代码签名，我甚至没有为此设置身份。

    • 所以，现在在我的README中，我提到了stack install和cabal install 。 但2016年最佳做法是什么？

    看过你的.cabal文件后，我发现你的依赖关系没有任何限制。 你至少应该有下限，最好是下限和上限。

    正如@Emanuel Borsboom所提到的，当您将包上传到Hackage时，您可以使用stack填充版本限制： 

    stack upload --pvp-bounds=both

    实际上，对于我建议的应用程序，包括cabal.config文件由cabal freeze在包中生成： 

    cabal freeze
mv cabal.config cabal.config-sample

    当遇到构建Hackage遗留应用程序的麻烦时，我经常希望作者包含这些信息。 您可以在以下cabal.config获取特定快照的cabal.config文件： 

    https://www.stackage.org/{RESOLVER}/cabal.config

    而在你的stack.yaml文件中，我会使用标准的LTS版本而不是nightly- 。 据说他们永远不会被删除。 另一方面，你将通过减少他们必须维护的快照目录的数量来帮助你的用户。

    链接地址: http://www.djcxy.com/p/92251.html

    上一篇: Best practices for distributing a Haskell application and updating it

    下一篇: Return type match with auto and friend function