Allow multiple env_prefix in for BaseSettings #4319
Replies: 3 comments
-
A use case I was looking at that this would help with is having a few general env variables that set username and password for multiple components/containers, but still allowing them to be overridden by a specific component by using that component's specific env_prefix. +1 to this feature. |
Beta Was this translation helpful? Give feedback.
-
I came accross this today and found a little workaround using the new Pydantic v2 from typing import Any, List, Tuple, Type
from pydantic.fields import FieldInfo
from pydantic_settings import (
BaseSettings,
EnvSettingsSource,
PydanticBaseSettingsSource,
)
class ExtendedEnvSettingsSource(EnvSettingsSource):
def get_field_value(self, field: FieldInfo, field_name: str) -> tuple[Any, str, bool]:
if prefixes := self.config.get("env_prefixes"):
for prefix in prefixes:
self.env_prefix = prefix
env_val, field_key, value_is_complex = super().get_field_value(field, field_name)
if env_val is not None:
return env_val, field_key, value_is_complex
return super().get_field_value(field, field_name)
class ExtendedSettingsConfigDict(SettingsConfigDict, total=False):
env_prefixes: List[str] | None
class ExtendedBaseSettings(BaseSettings):
@classmethod
def settings_customise_sources(
cls,
settings_cls: Type[BaseSettings],
init_settings: PydanticBaseSettingsSource,
env_settings: PydanticBaseSettingsSource,
dotenv_settings: PydanticBaseSettingsSource,
file_secret_settings: PydanticBaseSettingsSource,
) -> Tuple[PydanticBaseSettingsSource, ...]:
return (ExtendedEnvSettingsSource(settings_cls),)
class DebugSettings(ExtendedBaseSettings):
model_config = ExtendedSettingsConfigDict(
env_prefixes=("debug_", "nomad_meta_debug_"),
)
enabled: bool = False
wait_for_client: bool = False
port: int = 5678 Sometimes my environment is Reference: https://docs.pydantic.dev/latest/usage/pydantic_settings/#parsing-environment-variable-values |
Beta Was this translation helpful? Give feedback.
-
+1 This would be a really handy feature for dealing with environment name changes. Sometimes we would like to rename an environment variable required by a package, but still want to able to read from the old names if they are available, just for backwards compatibility. |
Beta Was this translation helpful? Give feedback.
-
When using BaseSettings, automatically loading variables from the env is very convenient. I use it, particularly in combination with docker containers. However, the env variables that these services have built-in might have multiple different prefixes. In the example below, RabbitMQ uses the prefix
RABBITMQ_DEFAULT_
(for username and password) andRABBITMQ_
(for ssl_verify).It would be great if multiple
env_prefix
could be supported. Then the loading could be completely automatic.It could like like this:
Beta Was this translation helpful? Give feedback.
All reactions