Replies: 1 comment
-
The chaining aspect is something I've dealt with, although not sure about the interpolation.. In case it helps, here is the package I wrote/use for my config
Happy to answer questions if you have any. It's a relatively lightweight package but you might find it more useful to copy some of the logic instead of using directly. Or perhaps I'm misunderstanding and it's not helpful at all. ;) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
My goal is to split ini files in parts that can be separately maintained and "aggregated".
My use case is having multiple installation of the same application with similar but different parameters. In my scenario some of the parameters are also sensitive (passwords and various secrets) others are system dependant.
I make large use of the
use = config:xxx.ini
directive to pack my shared conf in a chain using overrides where needed (a root for applications behaviour like jinja filters, than a system dependant for sizing of cache, remote end points and so on, and then a specific one for application where I'd make use of secrets).
I have somethin like production_1.ini that imports production_shared.ini that imports shared.ini, so that I can have a production_2.ini instead of 1, and similar chains for staging and development, all sharing the base "shared.ini".
My first point is that I can use the "use config" only in the [app:main] section, apparently and by no mean in the many loggers section. I'd rather need an import/include directive for that, but I can't find any.
My second issue is that I can not use multiple use of the directive to import the shared configurations AND the secret configurations separately. This requires to put them in a chain with some issues related to this.
A solution could be something like specific.ini -> secret.ini ->shared_env.ini -> shared.ini but for some reasons I don't like having a broken chain in the repo.
Third issue is that I can not use interpolation between different sections like the python config parser module seems to be able to do (like this: https://docs.python.org/3/library/configparser.html#configparser.ExtendedInterpolation)
I need this because I use email loggers that require user/password in the setup, but other situatons may occur.
My current best solution is to have (jinja) templates for the ini and a script that merges them in a new one substituting the secrets as required, but it's a little tricky.
I don't know if mixing all these issues up has any solutions, but due to the little documentation on the topic I'm just asking if there is a well known pattern to handle these issues that seems quite common to me.
Beta Was this translation helpful? Give feedback.
All reactions