haskell - stack.yaml 文件和 .cabal 文件的区别？

Question

在为您的项目指定外部依赖项时，我最近开始为 Haskell 使用堆栈。有时您将其放在 .cabal 文件中，而有时您将其放在 .yaml 文件中。

我是否认为当你把它放在 cabal 文件中时，它只会在你的包的堆栈存储库中查找。然而，当你把它放在你的 .yaml 文件中时，它也会在 Hackage 服务器中搜索，如果它在任何快照中都找不到它？

Answer 1

您项目的所有依赖项都进入 .cabal文件。不过，您是对的，有时您还会在 stack.yaml 中列出软件包。文件，这是可以理解的困惑。这是为什么？

好吧，.cabal文件总是表达你对包的依赖，但是 stack.yaml文件有效地配置了这些包的来源。通常，当使用 stack ，包来自 Stackage 基于您在 stack.yaml 中指定的解析器文件。然而，Stackage 并不包含 Hackage 中的所有包，并且它不打算——当您需要存在于 Stackage 之外的包时，您必须在 stack.yaml 中指定它们。文件。

为什么是这样？好吧，解析器自动将两个重要信息结合在一起:包名称和包版本。堆栈解析器提供了一个(弱)保证单个解析器中的所有包将一起工作，因此当一个包来自解析器时，无需手动选择您想要的版本。相反，Stackage 将为您做出决定。

从 Hackage 拉包时，您没有这种奢侈，因此您需要使用 extra-deps 指定包及其版本.例如，您可能有这样的事情:

extra-deps:
- crypto-pubkey-openssh-0.2.7
- data-bword-0.1
- data-dword-0.3

此条目具体确定应从 Hackage 而不是 Stackage 中提取哪些软件包的哪些版本。

在构建应用程序时，这似乎有点多余——您可以在 .cabal 中指定版本约束。文件，所以为什么要在 stack.yaml 中复制它们？文件？但是，在构建库时，区别更显着: .cabal文件表示库的实际版本约束(如果有)，但 stack.yaml文件精确指定在本地开发时实际安装的版本。

从这个意义上说， stack.yaml文件的用途类似于 Gemfile.lock或 npm-shrinkwrap.json其他包管理器的文件，尽管职责不像 stack 那样明确(部分原因是围绕 Haskell 的包系统如何工作的历史原因以及它过去存在的一些问题)。