尝试过把配置放在编程语言代码里吗？比YAML爽

本文将试着解释为什么大多数配置格式用起来都不太舒服，作者建议大家尝试使用一门真正的编程语言（例如，像 Python 这样的通用编程语言）来编写配置，通常这是一种可行的选择，且使用过程更感愉悦。

大多数现代配置格式都很糟糕

本节，我主要针对 JSON/YAML/TOML/ini 文件，这是我遇到过最常见的配置格式。

我们暂将这种配置称为常见配置（如果有更好的名字，欢迎在评论中留言，谢谢）。

大家可能遇到过如下情况：

JSON 没有注释，设计如此
大量配置无法重用

例如，虽然 YAML 在理论上支持重用 / 引用配置（他们称之为锚），但有些软件（如 Github Actions ）却并不支持。通常，开发者无法重用配置的一部分，必须复制粘贴。

.gitconfig 使用一个自定义语法来合并这些配置
不能包含任何逻辑

很多人认为这是一种积极的做法，但我认为，如果不能定义临时变量、辅助函数、替换字符串或连接列表，那就有点差劲。变通方法（如果有的话）通常也不好用，因为它们额外增加了认知开销。于是，出现了一批重新发明的编程语言：

变量和字符串插值：Ansible 使用 Jinja 模板(!) 进行变量操作。
Github Actions 为此使用了自定义语法

此外，他们有自己的一套函数来处理变量。你得为此学习一门从来都未曾想过要学习的新语言。

范围
- 例如，在 Github 操作中有几个针对于 env 指令的自定义作用域。
控制流
- for 循环：构建矩阵和“排除”总是让人头疼不已
- if 语句：例如，CircleCI 中的 when
无法被校验。可以校验配置语法本身（例如，检查 JSON 串的正确性），但无法做语义检查。这是因为在配置文件中没有逻辑。通常情况下，你必须编写一个辅助程序来检查配置，并在传递给程序之前调用。很少有程序会遇到这个问题，通常，使用简单的类型系统就可以发现程序中的细小错误。
YAML 的隐式转换和可移植性问题非常突出。这一点已经饱受非议，所以在此只提供一个相关链接，供感兴趣的读者自行了解：“ YAML：可能没那么好”

总结：我们在花时间学习没什么用处的语法，而不是在富有成效地完成工作。

解决方法

当遇到这些问题时会出现什么情况呢？通常最终会使用一种“真正的”（即通用的、图灵完备的）编程语言来解决问题：

编写一个过滤自定义注释语法的程序；
编写一个合并配置或使用模板引擎的程序；
编写一个“evaluate”配置的程序，在此过程中，常常需要为一门简单的函数式语言重新实现一个解释器；
编写一个校验配置的程序。

在大多数情况下，它就是类型检查的样板文件。你不仅要处理已解决的问题，而且得到的错误消息质量也不高，所有这些事情都会分散你在主要目标上的注意力。

使用一门真正的编程语言

其思想是用目标编程语言编写配置。这里我将使用 Python，但是，这一思想也适用于其他语言，只要足够动态即可（比如 Javascript、Ruby 等等）。这样，只需 import 或 evaluate 配置文件就可完成。

一个小例子：

config.py

from typing import NamedTuple

	
class Person(NamedTuple):

	
    name: str

	
    age: int

	
PEOPLE = [

	
    Person('Ann'  , 22),

	
    Person('Roger', 15),

	
    Person('Judy' , 49),

	
]

使用这个配置（如果你想知道为什么我使用 exec 而不是 import，请看看这个回复）：

from pathlib import Path

	
config = {}

	
exec(Path('config.py').read_text(), config)

	
people = config['PEOPLE']

	
print(people)

[Person(name='Ann', age=22), Person(name='Roger', age=15), Person(name='Judy', age=49)]

我觉得它很简洁。让我们看看如何解决上文所述问题：

注释：很明显，不需赘述
包含：很简单，使用 import

你甚至可以 import 正在配置的包，可以针对配置定义一个 DSL，它将在配置文件中进行导入和使用。

逻辑

你可以使用语言的语法和库。例如，单独使用像 pathlib 之类的可以节省大量重复配置。

当然，随意乱用可能会让人难以理解。就我个人而言，我宁愿接受语言被滥用，也不愿受限制。

校验

你可以将逻辑校验保留在配置中，以便在加载时进行检查。成熟的静态分析工具（如 JS flow、eslint、pylint、mypy）对此可以有所帮助。

缺点

互操作性

如果程序是用 Python 编写的，那没什么问题。但如果不是，或者稍后将以另一种语言（比如 C++ 之类的编译语言）重写它，该怎么办呢？

将来，软件是否无需解释器即可运行？现代的 FFI 很是繁琐，链接配置将相当棘手。

我们特别以 Python 为例，大多数现代 OS 发行版中都有它。那么，你可以按以下方式来做：

使 Python 配置可执行
在 main() 函数中构建配置，转换为 JSON 串并输出到 stdout

由于 Python 是动态的，所以无需样板文件即可执行此步骤。

在代码中执行 Python 配置（比如，使用 popen()），读取原生的 JSON 串并予以处理。仍然需要手动在代码中将配置反序列化，但这至少不像只使用 JSON 并手动编辑它那么糟。

通用编程语言很难推理

这多少有点主观。就我个人而言，我更有可能被一个过于冗长的普通文本配置搞得不知所措，我一直都更喜欢简洁的 DSL。其中一个重要因素是代码风格：我确信你可以使配置文件在几乎任何编程语言中都具有可读性，甚至根本不熟悉该语言的人也能够看得懂，最大的问题可能是安全性和终止检查。

安全性

例如，如果配置可以执行任意代码，那么它可能会窃取密码、格式化硬盘等。

如果配置是由你不信任的第三方提供的，那么，我认为普通文本配置更安全。然而，通常并非如此，一般都是用户自己控制自己的配置。

此外，也可以通过沙箱解决这一问题，是否值得这样做取决于项目的性质，但是如果你使用像 CI executor 之类的东西，无论如何都需要它。

另外要注意，使用普通文本的配置格式不一定能躲过这些麻烦。参见“ YAML：一般并不安全”。

终止检查

即使不关心安全性，也不希望配置会挂起程序。我个人从来没有遇到过这样的问题，但这里有一些潜在的解决方法可供参考：

为加载配置指定显式的超时时间
有些语言能够有所帮助，例如， Bazel Skylark

有人知道在通用语言中检查终止的保守的静态分析工具的例子吗？注意，使用普通文本配置并不意味着它不会无限循环，参阅 “Accidentally Turing complete” .

配置会花很多时间去 evaluate，虽然技术上需要在有限的时间内完成，请参阅 “Why Dhall advertises the absence of Turing-completeness” 。虽然 Ackermann 函数是一个人为设计的例子，但它表明如果你真的关心恶意输入，那么无论如何都要做沙箱处理。

为什么是 Python?

我发现出于以下原因，大家都特别喜欢用 Python 来编写配置文件：

几乎所有的现代操作系统中都有 Python
大家认为 Python 语法很简单（不是件坏事），所以 Python 配置很有可能不会比普通配置更难理解
数据类、函数和生成器构成了精简的 DSL 的基础
类型标注同时用作文档和校验

其实，你可以在大多数现代编程语言中获得类似的愉快体验（只要它们足够动态）。

还有谁在做这件事？

一些项目允许用代码作为配置：

Webpack ，Web 模块打包器，使用 Javascript 作为配置
setuptools ，安装 Python 包的标准方法

允许同时使用 setup.cfg 和 setup.py 文件。这样的话，如果你不能以普通文本配置完成你的需求，那么可以在 setup.py 中进行调整，从而使你可以在声明式和灵活性之间取得平衡。

Jupiter ，交互式计算工具

使用一个 python 文件配置输出。

Emacs ：大家都知道使用 Elisp 进行它的配置

虽然我一点也不喜欢 Elisp，但它确实使 Emacs 非常灵活，可以实现你想要的任何配置。另一方面，如果你曾经读过其他人的 Emacs 设置，那么你可以发现，当你允许使用通用语言进行配置时，有些事情可能很难操控。

Surfingkeys 浏览器扩展：使用 Javascript DSL 进行配置
Gradle 支持以 Groovy 和 Kotlin DSL 来编写构建文件
Awesome Window Manager 使用 Lua 进行配置
Guix 包管理器：使用 Guile Scheme 进行配置

有些语言是专门为配置而设计的：

Bazel Skylark 使用 Python 的一个子集来描述构建规则

虽然为了确保终止检查和确定性而特意对 Bazel 进行了限制，但是配置 Bazel 比我使用过的任何其他构建系统都要愉快得多。

Meson 构建系统：借鉴 Python 的语法
Nix ：专门为 Nix 包管理器设计的语言

虽然弄一门全新的语言让人感觉有点大材小用，但是仍然好过用普通文本来进行配置。

Dhall ：专门为配置文件设计的语言

Dhall 宣称自己是“JSON + 函数 + 类型 + 导入”。的确，它看起来很棒，解决了我上文列出的大部分问题。

Jsonnet ：JSON + 变量 + 控制流

它们之间的具体区别，请参阅其他配置语言间的比较

这种语言的缺点是还没有被广泛使用。如果你没有绑定目标语言，那么需要二次解析 JSON。

但是，至少它能使你可以愉快地编写配置。

然而，如果你的程序是用 Javascript 编写的，并且不与其他语言交互，那么为什么不直接用 Javascript 编写配置呢？

如果一个也不选要怎么办？

在使用普通文本配置的时候，我找到了一些减少那些问题的方法：

尽量少写配置文件

这通常适用于 CI 流水线配置（例如 Gitlab、Circle、Github Actions）或 Dockerfiles。通常情况下，这样的配置使用了大量的 shell 命令，如果不逐行复制，就不可能在本地运行。

是的，的确也有调试的方法，但是它们的反馈周期非常慢。

使用更适合设置本地虚拟环境的工具，如 tox-dev/tox
更多地采用 helper shell 脚本，并从你的流水线中调用它们

这多少有点令人沮丧，因为它引入了间接而分散的代码。但是，同时它也是一个优势，你可以剥离（例如 shellcheck）你的流水线脚本，使它更容易在本地运行。有时，如果你的流水线很短，你可以视情况做出自己的判断。让 CI 只负责为你设置 VM/ 容器、缓存依赖项和发布构件。

生成而不是手动编写

这样做的缺点是，相比于手工编辑而言，生成的配置可能会更分散。

你可以添加警告注释，提醒该配置是自动生成的，并附上生成器的链接，同时将配置文件设置为只读，以防止有人手动编辑。

此外，如果你正在实行 CI，可以将一致性检查作为流水线本身的一部分。

参考资料

（命令行）标记非常适用于配置

总体上，我同意这一观点，但是仍然有些情况是不适用于标记的。

它也容易泄露机密（密钥、令牌、密码）——无论是在你的 shell 历史记录中还是通过 ps 都可以看到。

Xmonad ：配置文件是可执行文件

一个有趣的方法，但不一定总是可行的，例如，你可能没有安装编译器。

Mage ：以 Go 编写用于 makefile 的工具
Dhall wiki：可编程的配置文件
扩展语言的演变：Lua 的历史——显然 Lua 已经开始成为配置语言
Cue ：定义、生成和验证数据的语言

我在网站上找了很久才找到一个代码例子，就在这里。

配置复杂性时钟：一个硬编码的例子

最后的问题

之于现在为什么 YAML 成为一个主流选择，我还没有答案。我相信，Ansible/CircleCI 或者 Github Actions 都出自于非常优秀的工程师之手，他们应该考虑过使用 YAML 的利弊。

欢迎大家在评论区留言，分享你在做配置时经受过的痛苦，以及是如何解决它的。

来源：oschina

链接：https://my.oschina.net/u/4333555/blog/4295403

标签

python

github

javascript

bazel

lua

emacs