When using CLI parsing, how to apply strict parsing for other sources?

[pycaw]

I can't just set strict on everything because then CLI parsing will fail so this has to be selectively applied per settings source.
I specifically want this to work with yaml source, but having it succeed with json would be a start as well.

My failing attempt:

from pydantic import ValidationError
from pydantic_settings import (
    BaseSettings,
    CliApp,
    JsonConfigSettingsSource,
    PydanticBaseSettingsSource,
    SettingsConfigDict,
    YamlConfigSettingsSource,
)


class Settings(BaseSettings):
    model_config = SettingsConfigDict(
        cli_parse_args=True,
        cli_kebab_case=False,
        validate_default=False,
    )

    mybool: bool

    @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, ...]:
        strict = True
        json = True

        if strict:
            # Doesn't quite help
            StrictBase = type(
                "StrictBase", (settings_cls,), {"model_config": SettingsConfigDict(strict=True)}
            )
            base = StrictBase
        else:
            base = settings_cls

        if json:
            """
            {
                "mybool": 0
            }
            """
            return (JsonConfigSettingsSource(base, json_file="myconfig.json"),)
        else:
            """
            mybool: 0
            """
            return (YamlConfigSettingsSource(base, yaml_file="myconfig.yaml"),)


def cli():
    try:
        settings = CliApp.run(Settings)
    except ValidationError:
        pass
    else:
        assert False  # "I want this assertion error to be raised but it doesn't happen"

[hramezani]

Thanks @pycaw for the issue. Can you confirm that the problem exists on main?

[pycaw]

Thanks @pycaw for the issue. Can you confirm that the problem exists on main?

Issue seems to persist as of a164b73

[hramezani]

Thanks @pycaw for checking.

@kschwab Please could you take a look when you have time?

[kschwab]

@hramezani to support this, we would need to update environment variables to support coercion of more types. i.e., the CLI just passes "env like strings" to the ENV source, which then takes care of final formatting. I think today there is some amount of coercion around lists and dictionaries, but it would need to be taken further to handle strict=true.

I created a quick example that highlights the issue:

from pydantic import BaseModel
from pydantic_settings import BaseSettings, CliApp

class DeepSubModel(BaseModel):
    my_bool: bool
    my_bool_list: list[bool]

class SubModel(BaseModel):
    my_int: int
    my_int_list: list[int]
    deep: DeepSubModel

class Settings(BaseSettings):
    my_str: str
    my_str_list: list[str]
    sub_model: SubModel

CliApp.run(Settings, cli_args=[
    '--my_str', 'hi',
    '--my_str_list', '["a", "b", "c"]',
    '--sub_model.my_int', '3',
    '--sub_model.my_int_list', '[1,2,3]',
    '--sub_model.deep.my_bool_list', '[true,false,true]',
    '--sub_model.deep.my_bool', 'true',
])
"""
CliSettingsSource parses CLI args into an "environment variables dictionary".
Note type is dict[str, str]:
{
  'my_str': 'hi',
  'my_str_list': '["a","b","c"]',
  'sub_model.my_int': '3',
  'sub_model.my_int_list': '[1,2,3]',
  'sub_model.deep.my_bool': 'true'
  'sub_model.deep.my_bool_list': '[true,false,true]',
}

EnvSettingsSource parses CLI "environment variables".
Note that list types are coerced, whereas non-list types are not:
{
  'my_str': 'hi',
  'my_str_list': ["a","b","c"],
  'sub_model.my_int': '3',  # Should be int 3 if strict=true supported
  'sub_model.my_int_list': [1,2,3],
  'sub_model.deep.my_bool': 'true',  # Should be bool True if strict=true supported
  'sub_model.deep.my_bool_list': [True,False,True],
}
"""

TL;DR - When strict=true, some environment variables that would have been coerced by settings_cls instantiation, now need to be coerced during dictionary construction.

[pycaw]

...
TL;DR - When strict=true, some environment variables that would have been coerced by settings_cls instantiation, now need to be coerced during dictionary construction.

But what about JsonConfigSettingsSource and strictness regarding?

[kschwab]

But what about JsonConfigSettingsSource and strictness regarding?

JsonConfigSettingsSource behaves differently. JSON inherently distinguishes between {"myint": 0} and {"myint": "0"}, so no coercion is needed at the source. When json.loads(...) parses the file, it produces a typed Python dict, which is then passed to Pydantic. If strict=True, a value like "0" for an int field will raise a validation error, as expected.

In contrast, EnvSettingsSource receives everything as a str. There's no formal spec (like JSON, YAML, TOML) governing the types, just raw strings from os.environ. These must be coerced into the expected types. Currently, this coercion is partially deferred to Pydantic, which works only if strict=False.

To support strict=True, EnvSettingsSource must perform full type coercion itself before handing data to Pydantic. This already happens for list and dict, but needs to be extended to all types.

[pycaw]

JsonConfigSettingsSource behaves differently...

But what about JsonConfigSettingsSource and strictness regarding?

JsonConfigSettingsSource behaves differently. JSON inherently distinguishes between {"myint": 0} and {"myint": "0"}, so no coercion is needed at the source. When json.loads(...) parses the file, it produces a typed Python dict, which is then passed to Pydantic. If strict=True, a value like "0" for an int field will raise a validation error, as expected.

In contrast, EnvSettingsSource receives everything as a str. There's no formal spec (like JSON, YAML, TOML) governing the types, just raw strings from os.environ. These must be coerced into the expected types. Currently, this coercion is partially deferred to Pydantic, which works only if strict=False.

To support strict=True, EnvSettingsSource must perform full type coercion itself before handing data to Pydantic. This already happens for list and dict, but needs to be extended to all types.

Sooo, what could I do to resolve my original problem here? It looks like lax parsing is happening with JSON/YAML source, and manually forcing strict won't help (and I am not walking into the trap of #673).

[kschwab]

Sooo, what could I do to resolve my original problem here?

That’s the fix: update EnvSettingsSource to fully coerce types before passing it to Pydantic.

@hramezani can provide more details on whether this is a wont fix or if there's a plan to address it.

[pycaw]

Sooo, what could I do to resolve my original problem here?

That’s the fix: update EnvSettingsSource to fully coerce types before passing it to Pydantic.

@hramezani can provide more details on whether this is a wont fix or if there's a plan to address it.

I honestly don't get this, you make it as if JsonConfigSettingsSource passed its stringified output to EnvSettingsSource. Why would the two need to interact? One reads strings on the CLI other parses a json file.

[kschwab]

Why would the two need to interact?

Because all sources ultimately get merged. Each source (CLI, ENV, JSON, YAML, etc.) independently parses its content into a Python dictionary. These dictionaries are then merged based on the priority defined in settings_customise_sources. The final merged dictionary is passed to the Pydantic model for validation.

For example:

• JsonConfigSettingsSource parses a file with {"myint": 0} → {"myint": 0}
• EnvSettingsSource parses MYINT=0 from os.environ → {"myint": "0"}

Depending on source priority:

• If JSON has higher priority → merged dict is {"myint": 0}
• If ENV has higher priority → merged dict is {"myint": "0"}

This merged dictionary is then passed to the Pydantic model. If strict=True, Pydantic will reject "0" from the merged ENV dictionary as an invalid int. The problem is that EnvSettingsSource currently relies on strict=False on the Pydantic model (not the source) to handle the coercion of "0" → 0. But when strict=True, that fallback no longer works.

So the answer to:

"When using CLI parsing, how can I apply strict parsing for other sources?"

Which implies CLI + JSON, YAML, etc., is:

update EnvSettingsSource to fully coerce types before passing it to Pydantic.

Why? Because CLI (which uses EnvSettingsSource internally) only partially coerces its content. If strict=True, coercion must happen before the data reaches Pydantic. Otherwise, it will throw errors for types that aren't coerced.

I think part of the confusion here is where strict=True is getting applied. It's not on a per source basis; it's only applied during final instantiation of the model itself, i.e. MyModel(**merged_dict_from_sources). Hopefully that helps clear it up.