-
-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to build a cascading settings resolver #223
Comments
I was exploring this earlier this week.. from my grep of the codebase it's not possible currently because If the current model was passed in the source itself could: a. retrieve the current value of attributes to help build new attributes This PR is an imperfect solution to this problem but goes some way to addressing it. Imperfect because the |
Thanks @trondhindenes for reporting this issue. Yes, as @mnbbrown described it is not possible right now. We have to postpone it to V3 because it will introduce a breaking change. |
@mnbbrown @trondhindenes what do you think about #326? Does this PR solve your problems? |
I believe it does, thank you! |
In our current config module we have the following logic:
This is done by invoking a series of config providers, from lowest-prioritoy up to highest. Each variable value can at any time be overwritten by the value from a higher-priority provider.
It seems to me that pydantic doesn't support this, because it seems to read top-down starting from the highest-priority provider. In my example I guess AWS SSM would be read first, and then any settings left unresolved would be left to the environment variable provider. That wouldn't work for us, since we need the env var provided-values to build the paths etc for aws ssm.
So I guess I'm asking:
Is it possible with pydantic-settings to build a hierarchy of "config sources" where one source relies on data provided by another?
The text was updated successfully, but these errors were encountered: