GHC如何真正處理版本控制？

Question

我們- haskellers -可能都知道什么陰謀地獄 。 嘗試升級我們的應用程序/庫時，由於安裝的版本不同且上限不匹配，我們會出現故障。

我不明白。 我查了一下：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 sandbox hc-pkg anywhere one might use ghc-pkg to do the other things one might do with ghc-pkg` to do the other things one might do with但沙箱本地。