Open DylanLukes opened 1 month ago
Currently I bypass this by simply using typing.cast
to cast Traversable
into Path
. This is a bit brittle as there's no guarantee pydantic_settings
won't eventually start using something Traversable
doesn't support, but at least today it does indeed work.
Thanks @DylanLukes for bringing this up.
Would you be interested in working on fixing and creating a PR?
There are issues with the typing for the file options for
SettingsConfigDict
:PathType | None
despite documentation indicating they accept lists (which indeed they do).https://github.com/pydantic/pydantic-settings/blob/bcbfd17affa5a90663c9afc5a7dc67b281a728dc/pydantic_settings/main.py#L43-L46
The documentation indicates this at: https://docs.pydantic.dev/latest/concepts/pydantic_settings/#other-settings-source
PathType
could, but does not not includeimportlib.resources.abc.Traversable
:https://github.com/pydantic/pydantic-settings/blob/bcbfd17affa5a90663c9afc5a7dc67b281a728dc/pydantic_settings/sources.py#L87
I should note that if one provides a
Traversable
, it does currently work, indicating the subset ofPath
functionality used bypydantic-settings
is within theTraversable
subset ofPath
.In the example below, I pass a
Traversable
, and I have verified in a test that it does indeed load the packaged resource file just fine.Motivation
A somewhat useful pattern is to package a default configuration file inside a Python package. For example:
And then have in
src/foobar/foobar.defaults.toml
:This currently works. However, it will not type-check.