settings

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Environment variables are strings only

Environment variables can only handle text strings because they are external to Python and must be compatible with other programs and the operating system. Any value read from an environment variable in Python will be a str, and any conversion to a different type or validation must be done in code.

Using Pydantic BaseSettings for configuration

FastAPI applications can use Pydantic's BaseSettings class to manage settings from environment variables. Import BaseSettings from pydantic and create a subclass with type annotations and default values, just like a Pydantic model. Pydantic reads environment variables in a case-insensitive way, so an upper-case variable like APP_NAME will match an attribute app_name, and automatically converts and validates the data to the declared types.

Installing pydantic-settings

The pydantic-settings package can be installed with 'uv add pydantic-settings' or included by installing FastAPI's all extras with 'uv add "fastapi[all]"'.

Settings as a dependency for easier testing

Instead of using a global settings object, you can provide settings through a dependency function that returns a Settings instance. This makes it very easy to override settings during testing by creating a dependency override for the get_settings function with custom configuration values.

Using .env files with Pydantic Settings

Pydantic Settings supports reading from .env files (dotenv format). To enable this, set the model_config attribute in your Settings class with env_file set to the filename. The python-dotenv package must be installed with 'uv add python-dotenv' for this to work.

Using @lru_cache to create Settings only once

To avoid reading the .env file repeatedly for each request, decorate the get_settings dependency function with @lru_cache from functools. This ensures the Settings object is created only once on the first call, and subsequent calls return the same cached object. The @lru_cache decorator returns the same value that was returned the first time instead of executing the function code again, making it work with any combination of function arguments.

lru_cache behavior with dependency functions

The @lru_cache decorator executes a function once for each unique combination of arguments, then caches and reuses the result for identical argument combinations. For dependency functions like get_settings() with no arguments, the same value is always returned on subsequent calls, while still allowing the dependency to be overridden during testing.

Organizing settings in a separate module

Settings can be placed in a separate config.py module file and imported into the main application file, following the pattern used in bigger applications with multiple files. This requires an __init__.py file in the same directory.

Give your agent this brain