Haskell Tool Stack是目前最流行的Haskell软件包管理器，其主要目标是使构建Haskell软件包具有可重复性。
但是栈方法的目标是找到一个巨大的无冲突的软件包修订集，并将其称为snapshot。这样，软件包维护者便被迫更新其软件包的依赖关系，以使其与最近的snapshot不冲突。
我不得不说，这种设计太理想了，无法在现实世界中工作。
为了进行比较，NPM（NodeJS的程序包管理器）通过一种更实际的方式实现了这一目标：它允许冗余。在a -> b, c; b -> d(v1); c -> d(v2)这样的依靠钻石的情况下，NPM只需分别为d和b安装两个不同版本的c。这样，使用软件包的用户可以依赖于诸如黑盒之类的软件包，而无需考虑其依赖之间是否存在冲突深层依赖。
我想知道为什么不将Stack设计为允许软件包的冗余修订是一些实际的原因。是否可以为Haskell实现这样的软件包管理器？实施过程中最难的部分是什么？
答案 0 :(得分：4)
是的，有可能。实际上，cabal在默认情况下曾经以这种方式工作。在转向nix风格的版本时，它已被放弃，但据我所知，再次进行此操作不会遇到技术问题。
也就是说，我对nix样式的构建的经验是，很少会发现将依赖关系树中的每个包都强制设置为特定版本会阻止您构建构建计划。我不确定stack是否也是如此-我经验不足-但至少对于cabal而言，这样做似乎没有什么好处，因此，具有更简单的故障模式的简单设计似乎更为可取。