RFC42 提出了两个稳定的部分。

1. Structural settings instead of stringly extraConfig

   NixOS RFC42 structural settings [nix-0003]

   • April 8, 2024
   • Jinser Kafka

   简单概括，就是将原本 module config 中硬编码的程序配置，改为使用结构化的 nix 数据，使其对应程序 config。

   例如 wakapi 使用 yaml 来作为配置文件，在 RFC42 之前，一个做法是写 str type 的 option 为 services.wakapi.extraConfig，直接将 yaml 内容写入此处，传递给 wakapi。

   options.services.wakapi.extraConfig = lib.mkOption {
       type = lib.types.str;
       description = lib.mdDoc ''
         The wakapi config content.
       '';
     };

   这么做显然有很多缺点，比如语法无法检查、选项合并困难等。

   在 RFC42 之后，不再推荐这种写法，而是提供了一种统一的结构化（structural）的 settings option。还是 wakapi：

   let
       format = pkgs.formats.yaml { };
     in
       options.services.wakapi.settings = lib.mkOption {
         type = lib.types.submodule {
           freeformType = format.type;
           options = { };
           default = { };
           description = lib.mdDoc ''
             The wakapi config settings.
           '';
         };
       };

   这里的重点在于 freeformType = format.type;，它允许 config 中写下 option 中未直接定义的选项。这些任意写下的选项，最后都可以通过 format.generate 以设定的文件格式写入。

   confFile = format.generate "wakapi.yaml" cfg.settings

   另外，options = { }; 中仍然可以写明确的 option，如果这么写的话，选项可以被类型检查和生成文档。

2. Balancing module option count

   NixOS RFC42 balancing module option count [nix-0004]

   • April 8, 2024
   • Jinser Kafka

   只是推荐 module 编写者平衡 option 的数量。适当地写 option，帮助生成合适数量的文档选项，但是不用把所有的选项都写出来，使后续维护困难。

另外，尽管 NixOS module 没有明确的 RFC 或 spec，但在 RFC42 中隐含地使用了 module 的部分结构。可以相信这部分的 module 结构是稳定，不轻易改变的。

options = {};
  config = {};