haskell - GHC 是如何真正处理版本控制的？

Question

我们——haskellers——可能都知道阴谋 hell 是什么。当尝试升级我们的应用程序/库时，由于安装的版本不同且上限不匹配，我们会失败。

我不明白。我检查过:GHC 按版本安装软件包。这意味着当您安装mtl时例如，您有多个文件夹 mtl ，每个版本安装一个。这听起来很棒，因为我们可以安装同一个包的多个版本，并且取决于 .cabal 中的上限。 ，我们可以选择我们想要使用的版本。

但是，在很多情况下，GHC 并不是这样工作的。如果您有上限，例如 mtl < 4.2 ，您将无法安装mtl-4.2或上层。我不明白为什么。为什么 cabal/ghc 不说“是的，我可以安装它，它实际上不会破坏任何东西，因为该项目使用我已有的版本，所以我将继续使用该版本”？

我想这是有充分理由的，也许是因为并发版本。如果您使用mtl-4.2并且您依赖于使用 mtl-4.1 的包，你会同时需要两个版本，这是不允许的。但是，GHC 可以默认为较低版本，并允许安装较高版本而不破坏任何内容。

关于这一点的另一点:如果这样做，我想对于很多版本，将很难跟踪我们真正使用的版本。有办法检查吗？我有时会使用 -v3标志以获取有关正在发生的情况的更多信息，但类似 ​​cabal dep-list会很好。也许它已经存在 ghc-pkg ？

Answer 1

这个问题有很多子问题，但我会解决一个。

它询问:“关于这一点的另一点:如果这样做，我想对于很多版本，将很难跟踪我们真正使用的版本。有没有办法检查这一点？我有时会使用-v3 标志来获取有关正在发生的情况的更多信息，但是像 cabal dep-list 这样的东西会很棒。也许它已经存在于 ghc-pkg 中？”

如果您在沙箱中运行，这个问题的其他元素似乎暗示您这样做，那么您可以调用cabal sandbox hc-pkg list来查看沙箱环境，并且通常使用cabal 沙箱 hc-pkg 任何地方都可以使用 ghc-pkg 来完成人们可能使用 ghc-pkg` 做的其他事情，但沙箱本地。