libconfini

In practice, there are still types, they are just validated by your application. I didn’t want Confetti itself to make assumptions. I wanted to give you the freedom to define your own custom types and keywords, like “on” and “off”, or even tri-states like “yes”, “no”, “maybe”. The problem with mandatory keywords, like “true” and “false”, is they box you into the English language. And which data types should be intrinsic is arbitrary, for example, TOML has data types for date and time, but JSON does not [1]. Where do you draw the line? Confetti let’s you decide. You might enjoy reading this take on the subject [2]. [1] https://toml.io/en/v1.0.0#offset-date-time [2] https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

I like CSV for the same reasons I like INI files. It's simple, text based, and there's no typing encoded in the format, it's just strings. You don't need a library. They're not without their drawbacks, like no official standards etc, but they do their job well. I will be bookmarking this like I have the ini critique of toml: https://github.com/madmurphy/libconfini/wiki/An-INI-critique... I think the first line of the toml critique applies to CSV: it's a federation of dialects.

Required reading for anybody considering using TOML for something: https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

I love me an INI. By far, IMO, the best human readable config syntax. Sure it's got some gotchas, like all old formats (CSV) there's no spec. But if I have the choice I'd go INI. It's simple and leaves the choices up to the program that's reading the file, because everything is a string. To me there's no difference in this articles argument that with INI people would have to remember about the idiosyncrasies of the python implementation related to comments, and people having to know and learn the correct syntax of TOML. I'd say remembering when and where you can comment is easier too. Either way it's personal preference. I do occasionally like to reread this though (because I'm boring): https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

Sounds like you and the INI guy agree here and honestly I'm coming around to it because for complex types you end up typing everything twice. https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

Personally I prefer INI over nearly all configuration formats. https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

you might want to read this fine piece of propaganda https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

I assume they used the "prepare.sh" script for that 50M file: https://github.com/madmurphy/libconfini/tree/master/dev/test... (you need to clone the repo to run it, because it depends on some other files in there). The file it generates is not valid TOML though; even if you fix the obvious syntax issues you run in to issues like: % tomlv ./big_file.ini Error in './big_file.ini': toml: line 35: Key 'section' has already been defined. Perhaps tomlc99 doesn't check for this; I didn't try it. Maybe I should add something to toml-test for this; while I agree that 50M files are somewhat rare[1] and that performance isn't a huge consideration, it's not entirely unimportant either, and this can give people a bit of a "is the performance of my parser horribly atrocious or roughly fine?" kind of baseline. [1]: One use-case I have is that I use