IDK what the best is, but I know for certain it’s not YAML.
TOML. Easy on the eyes and easy to grep and filter out comments.
I really like the way Fail2Ban handles it with a .local config. The default doesn’t need to be backed up, and the .local is most minimal and concise. I’m unaware of any other programs doing it that way. I have scripts that either execute sed or tee -a to config files, after making a backup copy of the original.
I don’t know which is the best, but yaml is the worst.
Uh no, the worst is a tie between XML and JSON.
XML because the syntax is hard to read and even harder to write, and JSON because you can’t do comments. WTF.
XML is a bit verbose but otherwise easy to understand. JSON5 supports comments.
And neither requires me to explain weird formatting nuances to devops engineers.
YAML is a pain to read (lists of structures are very messy), can’t be auto-formatted, and is full of weird “gotchas” (Norway, errant tabs, etc.) if you don’t do things “the right way.”
Requiring the use of whitespace in formatting is wrong. End of.
I instant exit on XML conf files. I have no idea how to parse the info, maybe I should. But there are too many tags and my eyes instantly glaze over when I see it!
If you want the file to be directly human readable/editable:
- TOML
- YAML
If you never need to look at it or edit it manually:
- JSON
JSON if it also has an online schema, and a reference to it in the JSON file. That way some editors can check for errors and hint to the user about it.
But the good old flat text-data, the ini format is consistent, readable, and easily understandable by less-technical users.
.el (Emacs Lisp), nothing beats using Lisp to configure a Lisp environment.
I like xml, but it isn’t the easiest to read.
I hate yaml with a burning passion. At least with JSON you can compress it all down.
If you have a problem, and use XML to solve it, you now have two problems
I’m no fan of XML. It looks messy and the schema is difficult to write, imo. XML works best as a markup language.
YAML could have been okay if it were stricter with what they consider strings, and used tabs instead of spaces.
Using whitespace was a mistake. I know all the kids love it but it’s just wrong. I’ve never had as much difficulty explaining json or xml to users as I have yaml.
Depends on the purpose of the software. In certain specific situations a plaintext *.txt is unbeatable.
An unstructured text document can be “unbeatable” for configuration how?
The “PURPOSE” is the keyword.
If the purpose of the software is to work in closed, offline environment with Mr. NOTECH operating it via “line 5: rotations per minute; line 6: temperature in Fahrenheit” commands, then trust me, it’s going to get the job done.
“unbeatable” and “get the job done” are very different claims. If you just have bare unlabeled numbers on “magic lines” in a file - sure you can work with that. But I’d hardly say it’s “unbeatable” compared to “anything else” for readability and clarity. It’s the type of thing programming classes have students do so they don’t have to introduce libraries or other concepts.
It’s very likely that Mr. NOTECH would be able to understand “TEMP_F: ###” just as easily as “put the temperature on line 6”. And it would likely be MUCH easier for Mr. NOTECH to look at a config file and read back to you what the temperature setting is. Especially if they haven’t worked with the software for long. As a bonus it would be easier for Mr. NOTECH to know whether the temperature should be in F or C. Or even Kelvin.
Unbeatabe, then.
I see, you’re not being serious.
I absolutely am. You’re simply overthinking it - the scenario I provided makes plaintext *.txt perfect.
Sure, we can spend the rest of the day inventing scenarios, where Mr. NOTECH will be manipulated remotely by aliens, and what then, but that’s an exercise in creativity, not a situation that needs to be taken into account.
TOML looks good but it’s rarely used
TOML does look good. Wow! I havent looked at it at all before.
It’s like yaml but simple, consistent, untyped, and you never need to escape any characters, ever.
Types and validation aren’t going to be great unless they’re in the actual code anyway.
Assuming you can trust whoever wrote the config file, I prefer if it’s executable code.
Not really fussed about what language. The point is it’s really handy to have simple logic checks like a basic if statement on an environment variable. I also like being able to split my config files up into multiple files - maybe with an environment variable to check which files will be loaded in.
