Stack的package.yaml和stack.yaml

问题描述

堆栈支持 hpack 的package.yaml配置文件，因为至少在，但是关于它与stack.yaml文件之间的差异的文档并不多.

Stack has supported hpack's package.yaml configuration files since at least around this commit, as far as I can tell, but there's not much documentation about the differences between it and the stack.yaml file.

我发现谈论它的几个链接之一是此文档 ，上面写着:

One of the few links I've found talking about it is this documentation, where it says:

因此，看来package.yaml提供了*.cabal文件配置功能的超集，就像stack.yaml文件一样.

So from this, it seems like package.yaml provides a superset of the *.cabal file's configuration ability, like the stack.yaml file also does.

此处的文档表示stack.yaml是配置文件:

... 后来说说package.yaml是用于存储依赖项:

...and later says that package.yaml is for storing dependencies:

有此相关问题，但遗憾的是没有澄清两个文件之间的区别.

There's this related question, but it sadly doesn't clarify the difference between the two files.

我一直在使用package.yaml进行项目的所有配置，而从不使用stack.yaml.

I've been using package.yaml for all my project's configurations, and never using stack.yaml.

那么，堆栈的package.yaml和stack.yaml文件之间是什么关系?如果/当他们的职责重叠时，使用哪种更好的做法?

So, what is the relationship between stack's package.yaml and stack.yaml files? If/when their responsibilities overlap, which is it better practice to use?

推荐答案

stack.yaml不提供*.cabal配置的超集.

*.cabal文件是程序包级别的配置.它可以由hpack从package.yaml生成.此配置提供有关程序包的基本信息:依赖关系，导出的组件(库，可执行文件，测试套件)以及构建过程的设置(预处理器，自定义Setup.hs).许多项目也不使用hpack，也没有package.yaml，只有一个*.cabal文件.

The *.cabal file is the package-level configuration. It can be generated by hpack from a package.yaml. This configuration provides essential information about the package: dependencies, exported components (libraries, executables, test suites), and settings for the build process (preprocessors, custom Setup.hs). Many projects also don't use hpack and don't have a package.yaml, only a *.cabal file.

stack.yaml文件是项目级别的配置，它指定特定的环境以使生成可复制，固定版本的编译器和依赖项.通常由解析器(例如lts-11.4)指定.

The stack.yaml file is the project-level configuration, which specifies a particular environment to make a build reproducible, pinning versions of compiler and dependencies. This is usually specified by a resolver (such as lts-11.4).

stack.yaml对于package.yaml而言不是多余的. package.yaml指定需要哪些依赖项. stack.yaml表示一种一致地解决依赖关系的方法(特定的软件包版本，和/或从何处获取依赖关系，例如:在Hackage，远程存储库或本地目录上).

stack.yaml is not redundant with package.yaml. package.yaml specifies what dependencies are needed. stack.yaml indicates one way to consistently resolve dependencies (specific package version, and/or where to get it from, for example: on Hackage, a remote repository, or a local directory).

stack.yaml对开发人员最有用:我们不希望我们的构建突然中断，因为在处理另一个项目时升级了依赖项，因此我们将所有内容都用stack.yaml固定.该文件对可能有外部约束的用户用处不大(通常，版本已由某些发行版修复).

stack.yaml is most useful to developers: we don't want our build to suddenly break because a dependency upgraded while working on another project, hence we pin everything with stack.yaml. This file is less useful to users, who may have external constraints (typically, versions are already fixed by some distribution).

• 在许多情况下，只需在stack.yaml中指定解析器即可.因此，新的stack用户通常无需担心配置stack.yaml.

• In many cases, just specifying the resolver in stack.yaml is enough. Hence new stack users usually don't need to worry about configuring stack.yaml.

解析器指定一组精选的特定版本的软件包(标准软件包在stackage.org上列出).如果所选解析程序缺少软件包的依赖项，则必须在stack.yaml的extra-deps字段中列出它.

A resolver specifies a curated set of packages with specific versions (the standard ones are listed on stackage.org). If a dependency of the package is missing from the chosen resolver, then it must be listed in the extra-deps field of stack.yaml.

一个项目可以跨越多个包，因此可以将它们添加到stack.yaml的packages字段中，因此可以在一个通用环境中构建它们并且相互依赖.

A project can span multiple packages, that thus get added to the packages field of stack.yaml, so they can be built in a single common environment and depend on each other.

另一个常见的用例是创建许多stack.yaml(具有不同的名称)以轻松测试各种配置(例如，GHC版本或软件包标志).

Another common use case is to create many stack.yaml (with different names) to easily test various configurations (e.g., GHC versions or package flags).

这篇关于Stack的package.yaml和stack.yaml的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！