21–30 of 67 posts
Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.
This year I started using an SQLite file specifically for config values Have used everything from Json to Cue and in-between. Tired of the context switch. Need to use SQL anyway. Fewer dependencies overall required.
Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.
I appreciate that the ts/js ecosystem seems to be moving in this general direction. Lots of config.json is being replaced by the nicer config.ts.
Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the application itself. Lets not also do that in configurations.
Earlier quoted context omitted.
Serious question: do people who work with these config files frequently, or on large such files, use simple text editors, or are there "smart" editors that do things like prevent you from making typos or inserting the wrong data type, similar to an HTML form that does basic validation or a DB schema that rejects bad data? There is no single cure-all, of course, but surely we should be relying on computers to do much…
I think one of the problems of those "configuration languages" is that you can extract semantic information without knowing the target, e.g., with has a specific meaning in GitHub Actions but it is otherwise an unremarkable word in the YAML specification. But when working with real programming languages it is completely different, you can take semantic information from the current code, and you can have things like t…
As someone who's spent most of their career in cloud IAC, and likes to think they are pretty read up on the latest going on in that world, if you didn't know better you'd think YAML is one of the greatest threats facing mankind. There are plenty of things I certainly hate about it, but every configuration syntax I've ever used I have similar gripes about. It's like once a month this kind of "The world is growing tire…
I'm trying to remember the phrase. Something like, "there is nothing as vicious as low stakes fights." Trying that on Google gets me https://en.wikipedia.org/wiki/Sayre%27s_law . Is about right. :D
Earlier quoted context omitted.
I appreciate that the ts/js ecosystem seems to be moving in this general direction. Lots of config.json is being replaced by the nicer config.ts.
I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it. Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the…
Actually that's not the biggest benefit (which is tests for schemas) but it's nice to have the “.ts” file actually log the actual config as JSON and then the app consumes it as JSON, rather than importing the .ts file and all its dependencies and having weird things like “this configuration property expects a lambda.”
Earlier quoted context omitted.
I appreciate that the ts/js ecosystem seems to be moving in this general direction. Lots of config.json is being replaced by the nicer config.ts.
I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it. Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the…
You need something between JSON/YAML and Python/JavaScript.
A config language makes the possibility space small.
It also makes it deterministic for CI and repeatable builds.
It also makes it parallelizable and cacheable.
Don't use your language for config. People will abuse it. Use a config language like Starlark or RCL.
Earlier quoted context omitted.
This year I started using an SQLite file specifically for config values Have used everything from Json to Cue and in-between. Tired of the context switch. Need to use SQL anyway. Fewer dependencies overall required.
Curious - how do you version the config?
The problem with configuration formats, is not syntax, or abstraction, it's the lack of consistent language server integration, it's problem when I can't lookup the definition for a key, the expected type, or quickly jump to definitions that clearly show which keys are available to configure.
Example: We are programming a backend for a blog. If we were to not use templates, but instead try to get that functionality via the webservice configuration we would have to "invent" some format that gives us the flexibility of templates within let's say a YAML file.
Needless to say that would be a horrible idea. Maybe I am being naive here, but I have yet to be convinced of the fact that it is really configuration formats that are the problem and not what people try to abuse them for. I have yet to work on a project where TOML wasn't enough for actual configuration.
Usually when I need something more complex than what can be done with TOML it is a sign that this needs to be handled differently. Via templates or with a database or making a special DSL-like script file. E.g. if you're using python nothing (except security considerations) stops you from allowing users to use a python file for configuration. If your configuration needs are really that complex, why not use a real programming language for it?