YAML文件在云原生生态系统的配置中占主导地位。Kuberentes、Helm、Tekton和许多其他项目都使用它们来定义自定义配置和工作流程。但YAML也有其怪异之处，这就是为什么云原生Buildpacks项目选择TOML作为其主要的配置格式。
TOML是一种最小的配置文件格式，由于其简单的语义，很容易阅读。你可以从官方文档中了解更多关于TOML的信息，但一个简单的构建包TOML文件看起来像这样。
api = "0.2"
[buildpack]
id = "heroku/maven"
version = "1.0"
name = "Maven"
与YAML不同的是，TOML不依赖于显著的空白和难以阅读的缩进。TOML被设计成人类可读的，这就是为什么它倾向于简单结构。它对机器来说也很容易读写；你甚至可以在不阅读TOML文件的情况下对其进行追加，这使得它成为一种伟大的数据交换格式。但数据交换和机器可读性并不是在Buildpacks项目中使用TOML的主要驱动力,而是人类。
戴上你的头盔
在你第一次使用Buildpacks时，你可能不需要写TOML文件。Buildpacks的设计是为了不影响你的工作，并消失在细节中。这就是为什么不需要像Helm values.yaml或Kubernetes pod配置那样的大型配置文件。
Buildpacks更倾向于惯例而不是配置，因此不需要复杂的定制来调整其工具的内部运作。相反，Buildpacks会根据应用程序的内容检测要做什么，这意味着配置通常仅限于由人类定义的简单属性。
Buildpacks还倾向于将基础设施作为命令式代码（而不是声明式）。Buildpacks本身是针对应用程序运行的函数，最好用更高级别的语言来实现，这可以使用库和测试。
所有这些属性都适合于简单的配置格式和模式，不需要定义复杂的结构。但这并不意味着使用TOML的决定很简单。
你能听到我吗，主要的TOML？
除了YAML或TOML之外，Buildpacks项目还可以使用许多其他格式，Buildpacks核心团队在项目早期也考虑过所有这些格式。
JSON具有简单的语法和语义，非常适合数据交换，但它并不是一种很好的人类可读格式；部分原因是它不允许有注释。Buildpacks将JSON用于机器可读的配置，如OCI图像元数据。但它不应该被用于人类编写的任何东西。
XML具有令人难以置信的强大属性，包括模式验证、转换工具和丰富的语义。它对于标记（如HTML）是很好的，但对于Buildpacks的要求来说，它是一种太沉重的格式。
最后，Buildpacks项目选择了TOML，因为它有可靠的现有技术（尽管该格式有些晦涩难懂）。在云原生生态系统中，containerd项目使用TOML。此外，许多语言生态系统工具，如Cargo（用于Rust）和Poetry（用于Python）使用TOML来配置应用程序的依赖性。
开始倒计时，引擎启动
TOML的主要缺点是它的普遍性。解析和查询TOML文件的工具（类似于jq ）并不容易获得，而且这种格式即使相当简单，对新用户来说也是很刺耳的。
每一个趋势都要从某处开始，云原生Buildpacks项目很高兴成为其中的一个项目，踏上了这扇门。
