3 ms·

This does work well. A team I was on at a past job did exactly this. On Unix the service literally ran `std::system("python config.py >config.json")` on startup

This does work well. A team I was on at a past job did exactly this. On Unix the service literally ran `std::system("python config.py >config.json")` on startup. The problem with this is that the answer to the question "what kind of configuration can I expect?" is "simulate the script and find out." If the script is written well, and is short, then the parameters that are filled in by the runtime environment are apparent. Over time, though, there is a risk that the script will not remain written well, and it almost certainly won't remain short.

siriusfeynman 2y ago
An approach I use is splitting my config tools into 2 stages Stage 1 creates a "explicit" config that can be exported to plaintext that contains exactly what is going to be created/modified with no abstraction/simplification Stage 2 applies the "explicit" config You get to be as clever as you want in stage 1 to avoid excessive copy pasting or not being able to know what your tool is going to do because all you have to go on is some homegrown DSL
iforgot22 2y ago
You run into the same problem with config DSLs, except now you're dealing with a DSL. Config is almost never going to be static.
- MathMonkeyMan 2y ago
  True. One advantage I can imagine for a DSL is that it constrains what is possible and optimizes (syntactically) what it's supposed to be for. I think that the author of Nix justified its language that way. The counterargument is "eventually you'll need every facility provided by a programming language, so just start with a programming language." I'm not sure how I feel about it. The YAML templating situation in Kubernetes is a [shit show][1]. Then again, I did once cave into the temptation of writing a [lisp-like XML preprocessor][2] to make my configurations less verbose. It doesn't have any access to the environment, though, so it's not a general purpose configuration language, just a shorthand for static XML. [1]: https://www.davidgoffredo.com/no-string-templates https://www.davidgoffredo.com/no-string-templates [2]: https://github.com/dgoffredo/llama https://github.com/dgoffredo/llama
  - iforgot22 2y ago
    What constraints are needed? I've used DSLs that are almost Python but not quite, I think because they were hermetic and deterministic. Even those ended up being produced dynamically using some higher level config DSL or just regular code. Like once you're doing RPCs, it's general programming language territory (though there are also DSLs that do this, which is cursed). And yes, I have very bad memories of Kubernetes YAML, also YAML itself.

siriusfeynman 2y ago

An approach I use is splitting my config tools into 2 stages Stage 1 creates a "explicit" config that can be exported to plaintext that contains exactly what is going to be created/modified with no abstraction/simplification Stage 2 applies the "explicit" config You get to be as clever as you want in stage 1 to avoid excessive copy pasting or not being able to know what your tool is going to do because all you have to go on is some homegrown DSL

iforgot22 2y ago

You run into the same problem with config DSLs, except now you're dealing with a DSL. Config is almost never going to be static.

MathMonkeyMan 2y ago
True. One advantage I can imagine for a DSL is that it constrains what is possible and optimizes (syntactically) what it's supposed to be for. I think that the author of Nix justified its language that way. The counterargument is "eventually you'll need every facility provided by a programming language, so just start with a programming language." I'm not sure how I feel about it. The YAML templating situation in Kubernetes is a [shit show][1]. Then again, I did once cave into the temptation of writing a [lisp-like XML preprocessor][2] to make my configurations less verbose. It doesn't have any access to the environment, though, so it's not a general purpose configuration language, just a shorthand for static XML. [1]: https://www.davidgoffredo.com/no-string-templates https://www.davidgoffredo.com/no-string-templates [2]: https://github.com/dgoffredo/llama https://github.com/dgoffredo/llama
- iforgot22 2y ago
  What constraints are needed? I've used DSLs that are almost Python but not quite, I think because they were hermetic and deterministic. Even those ended up being produced dynamically using some higher level config DSL or just regular code. Like once you're doing RPCs, it's general programming language territory (though there are also DSLs that do this, which is cursed). And yes, I have very bad memories of Kubernetes YAML, also YAML itself.