I recently implemented a config using pydantic-settings and found it quite extensible. For instance, I built a custom config source for SSM parameters that caches results and provides fall backs and specification for environment. Thinking about how we've done that in the past for Java apps is a whole messy thing.
There is a new version of yaml that fixes several of those problems, but many parsers are stuck on the old version, and besides, most people don't even know this is the case, not to mention you'd have to know which version your lib is using which even I forget to check.
I'll add it to the list of things to write. It's getting longer than I can produce articles :)
The main reason I use .yaml is the ability to make custom tags for the configuration.
For example, we use the tag !math to transform and evaluate math operations for results (it's much easier to understand 1/16 than 0.0625); !concat to concatenate strings; !range to generate a range of values; and other tags for internal config building for "inheritage" of data or removal of it.
Of course we need to define custom constructors for it and another program must implement those as well, but at the end it's also possible to write the same .yaml without these tags, it's just a tedious tasks for our users.
The ability to reference other fields is also a nice feature, making it possible to use node as variables similar to context data in a Jinja template, for example.
At the end we have a Pydantic model to validate the full schema (without the tags considered), so we basically have a "template language" using YAML itself
I recently implemented a config using pydantic-settings and found it quite extensible. For instance, I built a custom config source for SSM parameters that caches results and provides fall backs and specification for environment. Thinking about how we've done that in the past for Java apps is a whole messy thing.
Why do you consider YAML to be so much worse than JSON? The article you linked didn't seem to explain more than that.
Good question. I'm tempted to write an article about that. The problem is there are already a lot of them out there, not sure I'm providing value.
Here is one of the run down: https://noyaml.com/
Maybe I'll create my own.
There is a new version of yaml that fixes several of those problems, but many parsers are stuck on the old version, and besides, most people don't even know this is the case, not to mention you'd have to know which version your lib is using which even I forget to check.
I'll add it to the list of things to write. It's getting longer than I can produce articles :)
At least I will never have writer's block, lol.
The main reason I use .yaml is the ability to make custom tags for the configuration.
For example, we use the tag !math to transform and evaluate math operations for results (it's much easier to understand 1/16 than 0.0625); !concat to concatenate strings; !range to generate a range of values; and other tags for internal config building for "inheritage" of data or removal of it.
Of course we need to define custom constructors for it and another program must implement those as well, but at the end it's also possible to write the same .yaml without these tags, it's just a tedious tasks for our users.
The ability to reference other fields is also a nice feature, making it possible to use node as variables similar to context data in a Jinja template, for example.
At the end we have a Pydantic model to validate the full schema (without the tags considered), so we basically have a "template language" using YAML itself
I would use python or CueLang for that, tooling in YAML makes any logic addition quite a gamble.