Skip to content
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

Closed
trondhindenes opened this issue Jan 26, 2024 · 4 comments · Fixed by #326
Closed

How to build a cascading settings resolver #223

trondhindenes opened this issue Jan 26, 2024 · 4 comments · Fixed by #326
Assignees

Comments

@trondhindenes
Copy link

In our current config module we have the following logic:

  • Determine some basic info about the app such as app name, and environment name (from environment variables)
  • Then use these to optionally look up data from a settings store such as aws ssm parameter store or similar

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?

@mnbbrown
Copy link

I was exploring this earlier this week.. from my grep of the codebase it's not possible currently because __call__ in PydanticBaseSettingsSource doesn't get the current state of the settings model as an argument. See https://github.com/pydantic/pydantic-settings/blob/main/pydantic_settings/main.py#L181

If the current model was passed in the source itself could:

a. retrieve the current value of attributes to help build new attributes
b. decided if it should overwrite or not.

This PR is an imperfect solution to this problem but goes some way to addressing it. Imperfect because the current_state is untyped and it's a breaking change.

@hramezani
Copy link
Member

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.
I will mark it as a feature request and we can include this in V3

@hramezani
Copy link
Member

@mnbbrown @trondhindenes what do you think about #326?

Does this PR solve your problems?

@trondhindenes
Copy link
Author

I believe it does, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants