Best way to lazily instantiate Settings

[andersbogsnes]

In FastAPI, I generally adopt a lazy-loading pattern, starting from my Settings object (using the wonderful pydantic-settings), and then using Depends to pass my settings to my factory functions.

So I'd do something like:

#settings.py
from pydantic_settings import BaseSettings, SettingsConfigDict

class DBSettings(BaseSettings):
    db_url: str
    # load from .env file
    model_config = SettingsConfigDict(env_file=".env")

def get_settings() -> DBSettings:
      return DBSettings()

# db.py
import sqlalchemy as sa
from fastapi import Depends

def get_engine(settings: DBSettings = Depends(get_settings):
    return sa.create_engine(settings.db_url)

def get_conn(engine: Engine = Depends(get_engine)):
    with engine.connect() as conn:
        yield conn

And now my dependencies are nicely setup so that I can replace them at test time without having to worry about creating the necessary environment variables / .env file for testing purposes

I wanted to try out svcs to be able to have a single dependency being injected into my routes, since the function signature was getting really long. My question is, what's the best way to inject the Settings object down the line?

For async, there's an extra wrinkle, since the engine needs to have dispose be called, so I would need access to the engine object in the factory. For now I've got this:

@svcs.fastapi.lifespan
async def lifespan(_: FastAPI, registry: svcs.Registry):
    settings = DBSettings()
    engine = create_async_engine(settings.db_url)
    registry.register_factory(AsyncConnection,
                              engine.connect,
                              on_registry_close=engine.dispose,
                              ping=lambda conn: conn.execute(sa.text("SELECT 1")))
    yield

But like this I replace the settings object at test-time, and I'm back to having to set a bunch of ENVs or add a .env file.

Any ideas on how to best handle this scenario?

[hynek]

Isn't that pretty much what @madjar wrote in #34 (comment) or am I missing something?

Seems like another vote for #34?