Setting a `BaseSettings` field repeated times using different aliases in different settings sources results in `ValidationError` about pydantic-settings HOT 6 CLOSED

@sujuka99,

Thanks for the prompt response. After thinking about this more, I do think this is actually a bug. We guarantee that if an environment variable is specified in 2 locations (without an alias), we do prioritize and select appropriately, so I don't think the case should be any different when aliases are used.

I'll move this issue to pydantic-settings and we can work on a fix there 😄.

At the moment, you could set extra='allow' within the model_config on your FakeConfig class, but it's an unclean workaround for the time being.

from pydantic-settings.

similar to #148

from pydantic-settings.

Hi @sujuka99,

Thanks for reporting this 😄. The reasoning behind this is a bit complicated. So pydantic-settings parses your various environment settings sources correctly, and effectively generates the following input to your FakeConfig class:

{'bar_env': 'env', 'bar_init': 'init'}

However, the difficulty here is that then the following is occurring:

from pydantic import AliasChoices, BaseModel, ConfigDict, Field


class FakeConfig(BaseModel):
    bar: str = Field(validation_alias=AliasChoices('bar_env', 'bar_init'))

    model_config = ConfigDict(extra='forbid')


fc = FakeConfig.model_validate({'bar_env': 'env', 'bar_init': 'init'})

However, the nature of BaseSettings models is that they have the setting extra='forbid' set by default (shown explicitly above). So what's really happening is that bar is set to env, but then bar_init is recognized as an extra field. One option would be to set extra='allow' on your FakeConfig model, but then you'd get an extra bar_init field set on your model.

Hopefully that explanation of the behavior makes some more sense. We're set up to prioritize fields specified in more highly prioritized sources, but not in the case of different aliases.

If this is behavior that you'd like to see added, I suggest we move this to a feature request on the pydantic-settings repo 😄.

from pydantic-settings.

Hey @sydney-runkle, thanks for the thorough explanation! I would certainly like to see the behavior added 😄, should I move the request?

Ultimately I would want to replicate what Field(..., env=...) did in V1. Is there a way to achieve it in V2 currently?

from pydantic-settings.

Hello, please tell me what I'm doing wrong, this code worked before update 2.1.0 -> 2.2.1

from pydantic_settings import BaseSettings, SettingsConfigDict


class Base(BaseSettings):
    model_config = SettingsConfigDict(env_file='.env', env_file_encoding='utf-8')


class Settings(Base):
    model_config = SettingsConfigDict(env_prefix='APP_')
    ENVIRONMENT: str = ""
    REDIS_ADDRESS: str = ""
    MEANING_OF_LIFE: int = 0
    MY_VAR: str = ""


class ServerSettings(Base):
    model_config = SettingsConfigDict(env_prefix='SERV_')
    ADDR: str = ""


class GlobalSettings:
    app_settings = Settings()
    srv_settings = ServerSettings()


g_settings = GlobalSettings()

print(g_settings.app_settings.model_dump())
print(g_settings.srv_settings.model_dump())

.env

APP_ENVIRONMENT="production"
APP_REDIS_ADDRESS=localhost:6379
APP_MEANING_OF_LIFE=42
APP_MY_VAR='Hello world'


SERV_ADDR='localhost'

from pydantic-settings.

@D1maD1m0nd probably related to #245

If you get ValidationError complaining about extra fields, you can fix it by adding extra='ignore'

from pydantic-settings.