Hi! Thanks for modern-di and the rest of the modern-python libraries!

One thing that's holding me back from migrating to modern-di from that-depends is that many of my dependencies take plain values from a settings dependency, so each one ends up needing a factory function:

from modern_di import Group, providers
from pydantic_settings import BaseSettings


class Settings(BaseSettings):
    db_dsn: str = "postgresql://localhost/app"
    db_pool_size: int = 5
    cache_url: str = "redis://localhost"
    cache_ttl_seconds: int = 60


class Database:
    def __init__(self, dsn: str, pool_size: int) -> None: ...


class Cache:
    def __init__(self, url: str, ttl_seconds: int) -> None: ...


def create_database(settings: Settings) -> Database:
    return Database(dsn=settings.db_dsn, pool_size=settings.db_pool_size)


def create_cache(settings: Settings) -> Cache:
    return Cache(url=settings.cache_url, ttl_seconds=settings.cache_ttl_seconds)


class Dependencies(Group):
    settings = providers.Factory(Settings, skip_creator_parsing=True, bound_type=Settings, cache=True)
    database = providers.Factory(create_database, cache=True)
    cache = providers.Factory(create_cache, cache=True)

In a real app that's one function per component, each one copying fields into a constructor. The dependency group stops showing the wiring, and the wiring was what drew me to that-depends and modern-di.

What I was hoping to write is something like:

class Dependencies(Group):
    settings = providers.Factory(Settings, skip_creator_parsing=True, bound_type=Settings, cache=True)
    database = providers.Factory(Database, kwargs={"dsn": settings.db_dsn, "pool_size": settings.db_pool_size}, cache=True)
    cache = providers.Factory(Cache, kwargs={"url": settings.cache_url, "ttl_seconds": settings.cache_ttl_seconds}, cache=True)

But calling provider attributes this way doesn't work the way it does in that-depends.

In litestar-sqlalchemy-template I saw that settings aren't in the container at all: app/settings.py creates a module-level settings = Settings(), which is imported directly.

The snippet above already works if settings is that module-level instance, because kwargs accepts plain values. But then the values are fixed at import time, the environment has to be complete when the module is imported, and container.override(Dependencies.settings, ...) no longer reaches them in tests. Keeping settings overridable is one of the reasons I want them in the container.

Is keeping settings out of the container deliberate and the recommended pattern? If so, what's the reasoning, and how do you handle per-test settings with it?

Is there a pattern I'm missing that keeps both settings overridable and the group free of helper functions?

Thanks!