mirror of
https://github.com/kennethreitz/pydantic.git
synced 2026-06-05 23:00:18 +00:00
Samuel Colvin
33b7d52d31
* moving docs to mkdocs * transfering readme to md and more * fixing build * splitting usage.md * improving schema.md and index.md * fix make_history.rst * models intro * working on data conversation and required fields * more fixes to models.md * list all standard types supported * list of pydantic types * tweaks * update links in code * Apply suggestions from code review incorporate @dmontagu's suggestions. Co-Authored-By: dmontagu <35119617+dmontagu@users.noreply.github.com> * Apply suggestions from code review more missed suggestions. Co-Authored-By: dmontagu <35119617+dmontagu@users.noreply.github.com> * Apply suggestions from code review more corrects. * cleanup * Field order warning * fix and regenerate benchmarks * format examples better, cleanup * improve schema mapping table * correct highlighting file types in schema.md * add redirects in javascript * add logo
48 lines
2.4 KiB
Markdown
48 lines
2.4 KiB
Markdown
One of pydantic's most useful applications is to define default settings, and allow them to be overridden by
|
|
environment variables or keyword arguments (e.g. in unit tests).
|
|
|
|
```py
|
|
{!./examples/settings.py!}
|
|
```
|
|
_(This script is complete, it should run "as is")_
|
|
|
|
The following rules apply when finding and interpreting environment variables:
|
|
|
|
* When no custom environment variable name(s) are given, the environment variable name is built using the field
|
|
name and prefix, eg to override `special_function` use `export my_prefix_special_function='foo.bar'`, the default
|
|
prefix is an empty string. aliases are ignored for building the environment variable name.
|
|
* Custom environment variable names can be set using with `Config.fields.[field name].env` or `Field(..., env=...)`,
|
|
in the above example `auth_key` and `api_key`'s environment variable setups are the equivalent.
|
|
* In these cases `env` can either be a string or a list of strings. When a list of strings order is important:
|
|
in the case of `redis_dsn` `service_redis_dsn` would take precedence over `redis_url`.
|
|
|
|
!!! warning
|
|
Since **v1.0** *pydantic* does not consider field aliases when finding environment variables to populate settings
|
|
models, use `env` instead as described above.
|
|
|
|
To aid the transition from aliases to `env`, a warning will be raised when aliases are used on settings models
|
|
without a custom env var name. If you really mean to use aliases, either ignore the warning or set `env` to
|
|
suppress it.
|
|
|
|
By default `BaseSettings` considers field values in the following priority (where 3. has the highest priority
|
|
and overrides the other two):
|
|
|
|
1. The default values set in your `Settings` class.
|
|
2. Environment variables, e.g. `my_prefix_special_function` as described above.
|
|
3. Arguments passed to the `Settings` class on initialisation.
|
|
|
|
Complex types like `list`, `set`, `dict` and sub-models can be set by using JSON environment variables.
|
|
|
|
Case-sensitivity can be turned on through `Config`:
|
|
|
|
```py
|
|
{!./examples/settings_case_sensitive.py!}
|
|
```
|
|
|
|
When `case_sensitive` is `True`, the environment variable must be in all-caps,
|
|
so in this example `redis_host` could only be modified via `export REDIS_HOST`.
|
|
|
|
!!! note
|
|
On Windows, python's `os` module always treats environment variables as case-insensitive, so the
|
|
`case_sensitive` config setting will have no effect -- settings will always be updated ignoring case.
|