I'm sympathetic to that, but not to ini! INI is just standardized enough that your ini parser may or may not give you "just a string." As another poster mention

I'm sympathetic to that, but not to ini! INI is just standardized enough that your ini parser may or may not give you "just a string." As another poster mentioned, it may well interpret the string "NO", quotes included, as the boolean false, before passing along to the rest of the application. It's this ambiguity of type that makes INI problematic. If it simply handed along strings, without fail, and left the application to parse whether "NO" should be a country or boolean or string, that wouldn't be a problem. But inevitably, in order to DRY, somebody will make a consistent parser that is used in your application, whether that's in-house or a dependency. And at that point, it is very tempting to run everything through the parser, and the parser is going to make some unexpected decisions. So, sure, use INI. But don't really. Use a env file that is parseable as INI or as shell environment variables. As soon as you start needing anything more complex, use something where you have at least a few basic guarantees that what you're getting is at least in the general vicinity of what you want.