Posted by aleyan 2 days ago
To me there's no difference in this articles argument that with INI people would have to remember about the idiosyncrasies of the python implementation related to comments, and people having to know and learn the correct syntax of TOML. I'd say remembering when and where you can comment is easier too.
Either way it's personal preference. I do occasionally like to reread this though (because I'm boring): https://github.com/madmurphy/libconfini/wiki/An-INI-critique...
Having said that, there’s an official RFC for CSV, and INI files are de-facto specified by Microsoft’s implementation.
JSON is a fine over-the-wire format, but can’t we leave YAML in the dustbin and just do it ”properly” from now on? Please?
If you want a sensible compromise, it's to use something like Cue or Dhall to generate JSON configuration that's actually consumed by the software. There's also Jsonnet, but I've never been a fan.
I’m so over having to learn Go templates for a metrics exporter, or the need to write booleans as True or False for python apps, or some obscure Erlang syntax for RabbitMQ, or the batshit crazy APT config file syntax, or Apache's weird XML files… Just settle for a simple format and offer to load custom modules for those that need them.
But you can do that so easily as well! Like, take this YAML (substitute equivalent JSON or TOML, specific configuration language is irrelevant):
options:
someOption: 14
nested:
foo: "some string"
bar: true
I don't see how that's so much easier than this version in Lua: options = {
someOption = 14,
nested = {
foo = "some string",
bar = true
}
}
And when you do need to get a bit more complex, you have the the tools to manage that complexity. Like, if you have a bunch of very similar things (say, job definitions in CI/CD), you want a way to not repeat yourself so you only have to edit that once, YAML has a tool for that, "anchors" [1]. But it's obscure and a bit hard to use. In a real programming language, it's trivial: just stick the repetitive parts in a variable and use that. Or define a simple function in case most of the stuff is repeated, but some is not, so you can do foo = generateRepetativeConfig('specificOption')
Or maybe you can just do that with a simple for-loop. And if you want to do something like a string substitution, you have a whole dang language with the tools you need to do it.Dhall and languages like that are a big improvement, but really, I just want a normal programming language. We have decades of experience now with managing complexity in computer systems, and programming languages have evolved robust systems for handling that.
I agree that sandboxing and security can be a real concern for some of this stuff, in which case Starlark is perfect, though you can sandbox languages like Lua or various Lisps as well.
[1]: https://support.atlassian.com/bitbucket-cloud/docs/yaml-anch...
Ideally, the less power, the better:
- .env :: simple flat untyped key/value pairs. In practice, something like Pydantic can introduce hierarchy and type validation for the config - json :: simple, few data types. Can be read/written by humans - toml :: easier to edit by humans - json5 :: not in Python stdlib - yaml :: may require discipline, to avoid turing tarpit
As an intermediate between pure config and programming languages, jsonnet language can be used to generate json.
Turing complete: Ruby, Python, Lua, Lisp, etc — avoid for simple configs. They can be used as extension languages/ DSL
This would be far better than all random configuration languages out there and far more extensible.
I've been sketching on a shell/scripting language/system for a while and I've been thinking of it being in-effect three sub-languages, one nested within the other. At the lowest level: pure data, middle level: pure functional expressions, top level: imperative commands. I'd think that most use-cases for a configuration file would be satisfied by the lowest level, and some by the middle, but absolutely none would need the highest. Then a config file would be "sandboxed" by the language syntax, with very little risk of it breaking out.
What now?