11–20 of 163 posts
a bit from 5 months ago https://news.ycombinator.com/item?id=22707387
2018 https://news.ycombinator.com/item?id=17513770
2013 https://news.ycombinator.com/item?id=5272634
https://news.ycombinator.com/item?id=5274025
Alternative formats to this alternative format:
Generally I prefer actual code based configuration though, there's only a small subset of people than can read and edit these config formats but would be unable to configure something like DWM through real code (https://git.suckless.org/dwm/file/config.def.h.html) and this approach gives far more flexibility without code bloat. Once customization through config is removed it's only machine-to-machine configuration that changes and these are easily handled by TOML, INI or even environment variables.
Of configuration file formats, TOML is my favorite. It hits the right balance of power and simplicity, it's been able to handle my needs with minimal effort and fuss. I tried Python's INI for configuration, but it was both too simple and too complex at the same time, very frustrating. YAML is a nightmare, the formatting is way too easy to get wrong and accidentally break your configuration. JSON is too strict/simple.…
[info]
name = { first="bob", last="jones" }
info.name.first="bob"
info.name.first="jones"
I've always had a soft spot for the classic .INI style configuration. Modding command and conquer through "rules.ini" was always an adventure.
I've always had a soft spot for the classic .INI style configuration. Modding command and conquer through "rules.ini" was always an adventure.
TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…
In what situation is it not suitable to store these as strings, byte arrays as unbounded hex-encoded integers? 0xabcdef123400000000
As for your csv-example, I’d propose that if you have multi-value entries in a list like that large enough that it becomes unwieldy to repeat the property names every time (like in JSON or yaml), it really doesn’t belong in static configuration but in some kind of data store.
(And in the odd situation where that’s not the case, just use csv like you seem to prefer?)
I still don't understand why the Python steering committee decided to switch to this format for package configuration instead of the perfectly serviceable and existing setup.cfg. Packaging is already a pain to setup, now you gotta learn three (3) different ways to do it (if only to translate from one to the next) because everyone's split. The choice doesn't even matter very much, just settle on something whatever it…
I hope this catches on some more. I'm tired of being bitten by all the issues that I encounter with yaml configs.
TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…
databases:
db01: 10.1.2.3
db02: 10.1.2.4
filers:
user01: 10.3.10.1
user02: 10.3.10.2