configuration formats

johann

Configuration formats have the issue that they should be easy to read, understand and edit for humans, but also easy to read for machines. Many configuration formats seem to be bad at one or more of these. Be it indentation sensitivity, or being more on the serialization side (easy to read for machines but hard to edit for humans).

I think this article "an INI critique of TOML" gets to some interesting points.

Something that tosti came up with (and I wrote a parser for) was pretty similar to INI, you could probably call it a flavour.

So, is INI the best configuration format? (And perhaps exactly because it is under-specified?)

「 Fristi 」

The problem is, what do you define as "easy to read for humans" and "easy to read for a computer"? The latter would be simple to define, you'd want a format that takes the least amount of actions to read and interpret. INI, being as simple as it is, kinda ticks that box: one statement per line, and it can either be a section declaration in brackets, or a key-value assignment. That's about it for simple INI. Most other formats I see tend to be slightly more complex for the sake of allowing different datatypes, or constructs such as arrays or lists. Take JSON for instance. It's still pretty efficient for a computer to interpret since the structure is still pretty tight with not too many different kinds of possible things the computer can run into: but with the added luxury that you can define arrays, and the ability to distinguish between strings, integers, floats an booleans. Arrays can have named keys (making them json objects). I think ultimately you have to weigh between having a rich feature set and having a lighter language. So it kinda depends on what you need from the language. If you don't mind manually parsing values to see if they are integers or strings, INI is good. But if you need support for defining simple objects or want more clear datatypes, you might wanna look at others.

As for "what is easy to read for humans", I guess that's more ambiguous. It depends on the preferences of the person in question. However, you can state that the more technical characters are in the language, the more difficult it is to read for humans. INI is so stupid simple that it's probably the most human-readable configuration language. JSON by contrast may need formatting to become readable. Consider a JSON object with a bunch of sub-objects, but it's all written on a single line, no spaces. Perfectly readable for a computer, but hell for a human. In contrast, INI's structure is inherently preferable for a human because it already forces you to properly put every statement on its own line.

Getting back to your question, INI might not fill your functional needs (unless you use one of its expanded formats), but it sure as fuck is simple for both humans and computers.

toast

INI is a format that suffers from the lisp curse (it's so simple you can just write your own parser in a couple of hours even in C), but that's not necessarily a bad thing for configuration.
I think the true issue is in the very term "configuration format".

Why is TOML a configuration format at all, eh?
It's basically a database.
Schema verification is actually a bad thing unless you can truly verify the intended meaning.
Like if you're looking for, idk, a birth date, and tell TOML to look for a date, 0001-01-01 would be a valid type, but an invalid semantic.
But building semantic verification is very hard.
On the other hand, strict typing means more errors (for no good reason), way more complex parsing (for no good reason), and no significant advantages.

So why do people use JSON/TOML/etc as configuration?
Well they're not, they're using them as a seed database, lmao.
Configuration is human-facing, but databases are application-facing, and it's easier for a developer to write an application-facing thing as they are writing the application.
In that use-case, honestly, YAML is probably optimal.

However, for actual configuration, INI is most of the way there!
The reason for CNI existing is yes to standardize an INI dialect, but also to ensure it is compatible with CLI inputs (so you can unify CLI and File configuration schemas).
Which brings up a very specific point: calltime configuration is also configuration, and it makes sense for the calltime configuration and runtime configuration to have parity.

So I would say that INI is the best configuration format, and indeed in part because it's under-specified.
However, I can imagine configuration formats that are better under different ecosystems (e.g in a typed argv OS).
And if your true use-case isn't configuration but data management, it's not ideal either.

mycelium

In my opinion there are two kind of configurations:

the one for a public/broadly diffused software
the one for a private/restricted software

For the former, you should target a config format to be the simplest to configure, they should not need much experience in whatever but writing basic text. INI is a solid candidate for this purpose.

For the latter, you should use what's the most efficient for you or your technical stack because people using that software have a common ground of technical knowledge. Language specific configuration are relevant in this condition, e.g. config.py, config.exs, etc.

In any case, you have a single configuration entry point, or explicit precedence, e.g. config.ini → ENV → CLI flag -vvv
Nothing is more frustrating to change a config value to whatever without it being accounted, and discovering months later a file was overriding it 🙃