haskell - 什么是 cabal hell ？

Question

在阅读有关 cabal 的 hell 时，我有点困惑，因为这个词已经重载了。我猜最初 Cabal Hell 提到了菱形依赖问题，这是通过限制构建计划在每个构建计划中只有一个版本的任何包来解决的(一个包的两个不同版本不能存在于一个构建计划中)如本 answer 中所述.

但是，该术语也用于各种其他情况。例如破坏性的重新安装、不正确的包依赖边界(低/高版本边界)、不一致的环境......(或 Cabal 报告的任何其他错误)。

特别是其中，我对 1) 破坏性的重新安装和 2) 不一致的环境感到困惑？它们是什么意思，以及如何cabal new-build解决了这些问题(只是像 cabal sandbox 这样的沙盒)？还有什么作用ghc-pkg一定要在这里玩吗？

任何可以重现这些问题的引用资料或简单示例将不胜感激。

关于“破坏性重新安装”:如果我没记错的话，GHC 有一个自己的包管理器( ghc-pkg )，并且这些包被安装为动态可链接库，即:base取决于 ghc-prim , 所以如果 ghc-prim删除它会破坏 base ， 我对吗？而且由于 GHC 只允许同一版本的包的一个实例，cabal install可能会注册相同的更新版本 (package, version)这样它就破坏了未注册包的依赖项。如果上述关于“破坏性重新安装”的理解是正确的； cabal new-build怎么样在这里帮忙？

Answer 1

该术语唯一有意义的用法是链接答案中给出的那个。相关的是全局数据库中存在大量不同包的后续问题，这可能会使遇到钻石依赖关系更加普遍，需要破坏性重新安装才能解决等。

该术语的其他用法没有帮助，仅表示“以某种方式涉及 cabal 的问题”。

也就是说，让我回答你的其他问题。

1) ghc-pkg不是包管理器，而是管理 ghc 包数据库的工具。 cabal 使用它来将包注册到数据库中，最终用户可以使用它来检查数据库的内容。将其视为 ghc 提供的底层基础的一部分，而不是竞争工具。

2) new-build完全消除并替换了 packagedb 的标准概念。不是说数据库由包和版本组成，每对最多一个，而是一个数据库由任何给定版本的包的潜在多个副本组成，每个包可能具有其依赖项的不同版本，所有这些都在部分通过哈希寻址，因此由唯一的“指纹”标记。这称为 store .当你new-build , cabal 从头开始​​计算构建计划，而不考虑任何先前安装的依赖项。如果存储中已经存在特定指纹(由包、版本及其所有依赖项的版本、某些标志等组成)，则它会使用它。如果没有，它会计算它。

因此，唯一可能发生的“钻石依赖关系”是真正无法解决的依赖关系，而不是由于过早修复(由于已经安装的deps)依赖关系树的某些部分而引起的依赖关系。

tldr;你写“因为 GHC 只允许一个具有相同版本的包的实例”但是 new-build 部分解除了 store 中的这个限制。这允许求解器更频繁地生成更好、更可重复的计划。