stack.yaml文件& .cabal文件的区别? [英] stack.yaml file & .cabal file differences?

问题描述

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

I have recently started using stack for Haskell, when specifying external dependencies for your project. Sometimes you place it in the .cabal file while other times you place it in the .yaml file.

我想的是，当您将其放入cabal文件中时，它只会在堆栈存储库中查找您的包裹.但是，当您将其放置在.yaml文件中时，如果它在任何快照中都找不到，它还会在Hackage服务器中搜索?

Am I right in thinking that when you put it in the cabal file it only looks in the stackage repository for your packages. However when you place it in your .yaml file it also searches in the Hackage server, if it cannot find it in any of the snapshots?

推荐答案

项目的所有依赖项都放入.cabal文件中.但是，您是正确的，有时您还会在stack.yaml文件中列出程序包，这很容易引起混淆.为什么呢?

All of the dependencies for your project go into the .cabal file. You are correct, though, that sometimes you also list packages in the stack.yaml file, which can be understandably confusing. Why is that?

好吧，.cabal文件总是表示您对软件包的依赖性，但是stack.yaml文件有效地配置了这些软件包的来源.通常，使用stack时，程序包基于您在stack.yaml文件中指定的 resolver 来自Stackage.但是，Stackage并不包含Hackage中的所有软件包，也不旨在—当您需要位于Stackage之外的软件包时，必须在stack.yaml文件中指定它们.

Well, the .cabal file always expresses your dependencies upon packages, but the stack.yaml file effectively configures where those packages come from. Usually, when using stack, packages come from Stackage based on the resolver you specify in the stack.yaml file. However, Stackage does not include all the packages in Hackage, and it is not intended to—when you need packages that live outside of Stackage, you have to specify them in the stack.yaml file.

这是为什么?好的，解析器会自动将两个重要信息耦合在一起:程序包名称​​和程序包版本.堆栈解析器提供(弱)保证单个解析器中的所有软件包都可以一起工作，因此，当软件包来自解析器时，无需手动选择所需的版本.相反，Stackage会为您决定.

Why is this? Well, the resolver automatically couples two important pieces of information together: package names and package versions. Stackage resolvers provide a (weak) guarantee that all of the packages within a single resolver will work together, so when a package comes from a resolver, there is no need to manually pick which version you want. Instead, Stackage will decide for you.

从Hackage提取软件包时，您没有这种奢望，因此需要使用extra-deps指定软件包和.例如，您可能会有类似的内容:

When pulling packages from Hackage, you do not have this luxury, so you need to specify packages and their versions using extra-deps. For example, you might have something like this:

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

此条目专门确定应从Hackage(而不是Stackage)中提取哪些软件包的版本.

This entry determines specifically which versions of which packages should be pulled from Hackage rather than Stackage.

在构建应用程序时，这似乎有点多余-您也可以在.cabal文件中指定版本约束，那么为什么要在stack.yaml文件中重复它们呢?但是，在构建库时，区别要大得多:.cabal文件表示库的实际版本限制(如果有)，但是stack.yaml文件精确指定在本地开发时实际安装的版本.

When building an application, this might seem a little redundant—you can specify version constraints in the .cabal file, too, so why duplicate them in the stack.yaml file? However, when building a library, the distinction is a little more significant: the .cabal file expresses the actual version constraints of your library (if any), but the stack.yaml file specifies precisely which versions to actually install when developing locally.

从这个意义上讲，stack.yaml文件的作用类似于其他程序包管理器的Gemfile.lock或npm-shrinkwrap.json文件，尽管责任与stack不太明确(部分原因是由于有关Haskell的打包系统如何工作的历史原因以及它过去曾遇到的一些问题.

In this sense, the stack.yaml file serves a purpose similar to the Gemfile.lock or npm-shrinkwrap.json files of other package managers, though the responsibilities are not nearly as clear-cut with stack (in part due to historical reasons around how Haskell’s package system works and some of the problems it’s had in the past).

这篇关于stack.yaml文件& .cabal文件的区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！