So do JSON and TOML. If you think you need more than what they provide, something has gone very wrong.
>tools to avoid repeating yourself,
Bad. Config is not code. Settings should be explicit. DRY is not helpful.
Because of the lack of anchors/aliasing/variables etc, JSON has the nice property that you can parse it with exactly one upfront memory allocation: N bytes of JSON requires at most N words of memory.
>lord of ways to format strings so they stay readable
Bad. Too many ways: https://stackoverflow.com/a/21699210/6107981 No normal human being can remember all the rules for how a string gets parsed. Therefore it isn't actually human-readable or human-writeable, despite masquerading as such.
>arbitrary object serialization
You can write out the fields as a JSON object. If this isn't enough, then what you're trying to serialize doesn't belong in a human-readable text config file.
>Yaml only gets weird if you want to use complex objects as dict keys but that complexity is on you then.
This assumes the guy who wrote the config schema is the same as the guy who has to later use and edit it, which is seldom the case. When people do needlessly complicated config like this, they're taking an enormous stinking shit on my lawn for me to clean up.
> Bad. Config is not code. Settings should be explicit. DRY is not helpful.
I disagree. From experience, there are enough times that configuration requires repetition, loops, interpolation, etc, that you often end up in this gross space of either repeating chunks manually (error prone and brittle), or using code/templating to generate config (requires everyone on the codebase to use a specific toolchain).
HCL2 (used by Terraform) has been my favorite configuration system. It's just the right amount of power that I don't need copypasta or feel the need to resort to configgen. TOML is great for a single human-defined configuration for a program, but HCL does just as well at that, while also working for systems.
JSON definitely fails as human-editable. Again, you need some tooling to ensure syntax correctness.
> JSON has the nice property that you can parse it with exactly one upfront memory allocation: N bytes of JSON requires at most N words of memory.
I really don't care how much memory is allocated during parse, within reason, as long as execution is bounded, can't blow up, or otherwise misbehave.
>I disagree. From experience, there are enough times that configuration requires repetition, loops, interpolation, etc, that you often end up in this gross space of either repeating chunks manually (error prone and brittle), or using code/templating to generate config (requires everyone on the codebase to use a specific toolchain).
In such a case, use a Python script to generate the configuration, and then commit that generated config into source control. Keep the script and the generated config together in the same repo. You can set up a commit hook to keep them in sync. That way you can see explicitly what the configuration is, while reducing the repetition in the editing process.
>JSON definitely fails as human-editable. Again, you need some tooling to ensure syntax correctness.
What kind of tooling are you talking about here, other than syntax highlighting? I'm really at a loss to imagine how editing JSON by hand could be hard, other than maybe the lack of trailing comma. There's just not that much to it.
> In such a case, use a Python script to generate the configuration, and then commit that generated config into source control. Keep the script and the generated config together in the same repo. You can set up a commit hook to keep them in sync.
I can't really understand how all of that is simpler than having your config file have a little power in itself. Especially when that power is as easy as "use ruamel." You can't enforce commit hooks so you end up making it a build failure and that's honestly really annoying to have to push again because "right I forgot to run the config generating thing." And you're one ci.skip away from messing your system up.
Like it's adding failure modes
for such little gain. If you really must have the final generated output then save it as a build artifact for inspection later.
So do JSON and TOML. If you think you need more than what they provide, something has gone very wrong.
>tools to avoid repeating yourself,
Bad. Config is not code. Settings should be explicit. DRY is not helpful.
Because of the lack of anchors/aliasing/variables etc, JSON has the nice property that you can parse it with exactly one upfront memory allocation: N bytes of JSON requires at most N words of memory.
>lord of ways to format strings so they stay readable
Bad. Too many ways: https://stackoverflow.com/a/21699210/6107981 No normal human being can remember all the rules for how a string gets parsed. Therefore it isn't actually human-readable or human-writeable, despite masquerading as such.
>arbitrary object serialization
You can write out the fields as a JSON object. If this isn't enough, then what you're trying to serialize doesn't belong in a human-readable text config file.
>Yaml only gets weird if you want to use complex objects as dict keys but that complexity is on you then.
This assumes the guy who wrote the config schema is the same as the guy who has to later use and edit it, which is seldom the case. When people do needlessly complicated config like this, they're taking an enormous stinking shit on my lawn for me to clean up.