If your idea of a good configuration file format is JSON, you are not a daemon I will ever run voluntarily.

[cks@mastodon.social]

If your program's configuration file format is JSON, you're openly advertising that you care far more about programming convenience in reading and loading your configuration file than you do about the people operating your software. "You can generate our JSON with software from something else", yeah, no. You've told me what your priorities are and I'm going to believe you. I would rather run software that actually cares about the people running it.

[untitaker@gts.woodland.cafe]

@cks json5 is fine in your book, right?

[cks@mastodon.social]

@untitaker JSON5 is moderately less hostile than JSON but for most programs it's still advertising that you care a lot more about programming convenience than having a good experience of writing configuration files.

(For both simple and complex configuration files there are much better syntaxes that are easier for people to deal with.)

[jef@mastodon.social]

@cks @untitaker My most recent project uses tab-separated values that a script turns into XML. I assume you hate everything about this.

[davecb@hachyderm.io]

@cks I'm inclined to think the same about yaml.

It gets used for configuration in the sense that any extension language can be used as a configuration language.
The syntax is so <expletive deleted/> that it reminds me of the time some idiot added if-then-else to xml itself.

<p:if xmlns:p="http://www.w3.org/ns/xproc" test="/person/age &gt;= 18">
<p:then>
<status>adult</status>
</p:then>
<p:else>
<status>minor</status>
</p:else>
</p:if>

[cks@mastodon.social]

@jef @untitaker I think tab separated values (with comments, I hope) are a perfectly good format; I have a lot of configuration file formats in my own tools that are basically lines of 'a b'. What you turn them into internally is not my (sysadmin) problem.

[cks@mastodon.social]

@davecb I don't like YAML all that much but at least it has comments and forces people to write multi-line things and so on. It's more or less a tolerable universal solvent at this point, although it's not actively good the way a configuration file format could be.

(If you don't need nesting there are simpler general formats like TOML.)

[gumnos@mastodon.bsd.cafe]

@cks

It's one of the things I love about UCL-style syntax…pretty much every time I've encountered it, the syntax feels like it was targeted more at users rather than devs.

GitHub - vstakhov/libucl: Universal configuration library parser

Universal configuration library parser. Contribute to vstakhov/libucl development by creating an account on GitHub.

GitHub (github.com)

[davecb@hachyderm.io]

@cks I vaguely remember doing nesting in toml.

[servers]
[servers.alpha] ip = "10.0.0.1" dc = "eqdc10"
[servers.beta] ip = "10.0.0.2" dc = "eqdc20"

Are we talking about the same thing?

[waffles@masto.yttrx.com]

@cks I used to use a sandwich combination of = separated kv pairs in a global config, followed by libpopt ( https://manpages.debian.org/testing/libpopt-dev/popt.3.en.html ) to handle runtime overrides with an additional override of a per user override kv config file.

It was very user friendly but a huge PITA from a developer perspective.

Now all software I wrote (for work) uses straight up JSON for inputs. But that json is generated from thrift schemas which are managed by a python DSL, so it all kinda works.