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

BaseSettings: Customization of field value priority via Config #32

Closed
3 of 4 tasks
espdev opened this issue Oct 18, 2020 · 4 comments
Closed
3 of 4 tasks

BaseSettings: Customization of field value priority via Config #32

espdev opened this issue Oct 18, 2020 · 4 comments

Comments

@espdev
Copy link

espdev commented Oct 18, 2020

Checks

  • I added a descriptive title to this issue
  • I have searched (google, github) for similar issues and couldn't find anything
  • I have read and followed the docs and still think this feature/change is needed
  • After submitting this, I commit to one of:
    • Look through open issues and helped at least one other person
    • Hit the "watch" button on this repo to receive notifications and I commit to help at least 2 people that ask questions in the future
    • Implement a Pull Request for a confirmed bug

Feature Request

Currently, there is field value priority (from the docs):

In the case where a value is specified for the same Settings field in multiple ways, the selected value is determined as follows (in descending order of priority):

  1. Arguments passed to the Settings class initialiser.
  2. Environment variables, e.g. my_prefix_special_function as described above.
  3. Variables loaded from a dotenv (.env) file.
  4. The default field values for the Settings model.

However, in some cases it would be nice to swap 1 and (2,3) priorities. For example, I would like to create the configuration system based on config files (YAML, TOML, INI, etc) and env vars where envvars/dotenv have highest priority (env vars override values from config files that looks reasonable in some cases just like now env vars (2) override dotenv file (3)).

It might look something like this:

class Settings(BaseSettings):
    ...

s = Settings(**load_from_config_file(config_path))

In this case values from config file will override values from env vars.

Currently, the default behavior cannot be changed without subclassing BaseSettings class and overriding _build_values method. This is not mentioned in the current docs but previously it was mentioned (see pydantic/pydantic#340, pydantic/pydantic#341, pydantic/pydantic#343).

Would you mind considering the customization of this behavior via Config of BaseSettings model?

@layday
Copy link

layday commented Oct 20, 2020

This was briefly discussed deep in a PR: pydantic/pydantic#1011 (comment).

@layday
Copy link

layday commented Oct 22, 2020

Perhaps a way this would work would be to introduce a new Config option for BaseSettings, e.g. env_has_prio which would default to False. If True the order would become 2, 3, 1, 4. I don't think there is a use case for lifting .env above env vars.

@samuelcolvin
Copy link
Member

See my suggestion for a more powerful way to achieve this: pydantic/pydantic#2107 (comment)

@dmontagu dmontagu transferred this issue from pydantic/pydantic Apr 26, 2023
@hramezani
Copy link
Member

You can do it by change source priority in pydantic-settings

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