SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.
But that, and the parent's idea of binary formats in general, throws away the absolute golden property of text format configuration files: you can put those in git, and see with an accuracy of a single character what has changed. My impression was always that this was a huge reason for plain text files in the first place.
Someone mentioned protobufs, maybe with something like those one could have both?
> you can put those in git, and see with an accuracy of a single character what has changed.
You can use sqldiff[1]. Try adding it to your .gitattributes[2]. If you need TRIGGERs and VIEWs, consider dumping your database[3] instead.
[1]: https://www.sqlite.org/sqldiff.html
[2]: https://git-scm.com/docs/gitattributes
[3]: https://gist.github.com/peteristhegreat/a028bc3b588baaea09ff...
They don't type check though; most constraints arent enforced, and the underlying reality (slinging around mostly strings) leaks out often.
I agree this a pretty choice.
Re:YAML: Probably not so great after all
by becauseiam on Sunday August 18, 2019 @07:44PM
(#20733683)
Property Lists already do tick some of those boxes.
1. Built-time validation (or at least type checking).
2. Built configs can be easy to parse but (potentially) rich enough to avoid confusing templating.
3. Separation of concerns between storing/maintaining configs and applying them. E.g. scoop text configs off a source repo, but send out binary configs over the network.
All this is a fantasy in my head. Right now the closest mainstream thing is protobufs. But they make trade-offs for non-config use cases, and thus don't really cut it in the "... rich enough to avoid confusing templating" department.