▲ | atoav 3 days ago | ||||||||||||||||||||||
One pitfall that is so obvious it hurts (but I have seen people fall into it), goes a bit like this: 1. We have a python application 2. We need a configuration format, we pick one of the usual (ini/toml/yaml/...) 3. We want to allow more than usual to be done in this config, so let's build some more complex stuff based on special strings etc. Now the thing they should have considered in step 3 is why not just use a python file for configuration? Sure this comes with pitfalls as you now allow people who write the config to do similar things than the application, but you are already using a programming language, why not just use it for your overly complex configuration? For in house stuff this could certainly be more viable than writing your own parser. | |||||||||||||||||||||||
▲ | 10000truths 3 days ago | parent | next [-] | ||||||||||||||||||||||
Because now, anything that wants to read that config has to be written in Python. You've chained yourself to a stack just for a dynamic config. I ran into this issue at a previous job, but with a service that leaned heavily on hundreds of Django models. It made it impossible to use those models as a source of truth for anything unless you used Python and imported a heavyweight framework. It was the biggest blocker for a C++ rewrite of the service, which was really bad because we were having performance issues and were already reaching our scaling limits. Declarative configs are preferable for keeping your options open as to who or what consumes them. For cases where config as code is truly necessary, the best option is to pick something that's built for exactly that, like Lua (or some other embedded scripting language+runtime with bindings for every language). | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | IshKebab 3 days ago | parent | prev | next [-] | ||||||||||||||||||||||
This can sometimes be a good idea. But it isn't without downsides. Now your config file is Python and capable of doing anything Python can do (which isn't necessarily a good idea), it's no longer safe, you now have to deal with shitty Python tooling, you might have to debug crashes/lockups in your config files, you can no long switch implementation languages, etc. etc. It isn't a magic solution. | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | gaogao 2 days ago | parent | prev [-] | ||||||||||||||||||||||
One improvement though is using Starlark, instead of directly Python, since it offers a lot of advantages for a more lightweight runtime and parallelism. |