Where should dependency wiring live in a Python app?

Python does not need a dependency injection container by default.

For small applications, direct constructor calls are usually the best option:

repo = UserRepository(settings.database_url)
email = EmailSender(settings.smtp_url)
use_case = RegisterUser(repo, email)

This is explicit, readable, and has no moving parts.

The question appears later, when the same service graph starts showing up in multiple places:

• FastAPI startup;
• request handlers;
• Typer commands;
• background workers;
• local scripts;
• integration tests.

At that point, the problem is not "how do I inject everything?"

The better question is:

Where should application wiring live?

The boundary I want

The boundary I like is simple:

• FastAPI adapts HTTP;
• Typer adapts CLI commands;
• workers adapt jobs;
• tests adapt fixtures;
• the application owns service wiring.

Repositories, gateways, clients, and use cases should depend on normal Python types.

They should not care whether they were called from an HTTP request, a CLI command, a queue worker, or a test.

FastAPI Depends is an adapter, not the whole composition root

FastAPI Depends is great at the request boundary.

It works well for:

• request data;
• authentication;
• headers and cookies;
• request-scoped adapters;
• exposing app state to handlers.

But if the same service graph is used outside HTTP, I do not want that graph to live only in Depends.

A worker or CLI command should not need FastAPI dependency resolution to create an application service.

A cleaner shape is a plain composition root:

def build_services(settings: Settings) -> Services:
    client = ApiClient(settings)
    repo = UserRepository(client)
    email = EmailSender(client)

    return Services(
        register_user=RegisterUser(repo, email),
    )

FastAPI can adapt this graph in lifespan:

@asynccontextmanager
async def lifespan(app: FastAPI):
    app.state.services = build_services(load_settings())
    yield

And handlers can receive services through small dependency helpers:

def get_register_user(request: Request) -> RegisterUser:
    return request.app.state.services.register_user

Workers and CLI commands can use the same builder directly:

services = build_services(load_settings())
services.register_user.execute("ada@example.com")

The rule of thumb:

FastAPI adapts HTTP. The application owns service wiring.

Typer has the same boundary

Typer commands should usually stay thin:

@app.command()
def sync_users() -> None:
    command = build_sync_users_command()
    command.run()

That works for small CLIs.

When commands share settings, clients, repositories, and services, the same idea applies:

def build_services(settings: Settings) -> Services:
    client = ApiClient(settings)
    repo = UserRepository(client)

    return Services(sync_users=SyncUsersCommand(repo))

Then Typer is only the command adapter.

Tests and workers can reuse the same service graph without importing Typer.

Start with factories

I would still start with plain factories.

A few constructor calls are clearer than any container:

def build_register_user(settings: Settings) -> RegisterUser:
    client = ApiClient(settings)
    repo = UserRepository(client)
    email = EmailSender(client)

    return RegisterUser(repo, email)

This is the right default.

A container becomes useful later, when the same graph starts repeating across entrypoints and tests.

Where Injex fits

I built Injex for that middle ground.

It is not a provider framework. It is not a replacement for FastAPI Depends. It is not meant to hide application architecture.

The niche is small Python apps that want:

• explicit registrations;
• constructor injection from type hints;
• singleton, transient, and scoped lifetimes;
• temporary test overrides;
• graph validation before startup;
• zero runtime dependencies.

Example:

from injex import Container

container = Container()

container.add_instance(Settings, settings)
container.add_singleton(ApiClient)
container.add_transient(UserRepository)
container.add_transient(EmailSender)
container.add_transient(RegisterUser)

container.assert_valid()

use_case = container.resolve(RegisterUser)

Application services stay plain:

class RegisterUser:
    def __init__(self, repo: UserRepository, email: EmailSender):
        self.repo = repo
        self.email = email

No container imports in the service. No framework imports in the service. No decorators required for constructor injection.

Why graph validation matters

One useful feature of a container is validating wiring before the first real request or job.

container.assert_valid()

That can catch:

• missing registrations;
• missing type annotations;
• dependency cycles;
• invalid lifetimes.

This is useful in startup checks and CI smoke tests.

The service constructors do not need to run for validation, so real network clients or database sessions do not have to be created just to check the graph.

Performance in 1.3.0

Injex 1.3.0 focused on two things:

1. cleaner internals;
2. faster repeated resolves.

The internals are now split into focused modules:

• container.py;
• planning.py;
• registry.py;
• errors.py.

For repeated resolves, Injex caches dependency plans and uses a fast path for common constructor-injection graphs.

I added a reproducible benchmark for this graph:

• singleton Settings;
• singleton ApiClient(settings);
• transient UserRepository(client);
• transient EmailSender(client);
• transient AuditLog(settings);
• transient RegisterUser(repo, email, audit).

Local result

This is not a universal ranking.

Different graphs, lifetimes, async resources, framework integrations, and request scope models can change results.

The benchmark answers a narrower question:

Can explicit typed wiring stay small and fast?

For this graph, yes.

Reproduce it: uv run --with punq --with lagom --with dependency-injector --with wireup \ python benchmarks/resolve_graph.py

When I would not use Injex

I would skip Injex when:

• manual wiring is still clear;
• all dependency resolution happens inside one framework;
• the app needs a large provider/configuration DSL;
• the team does not want a container.

Manual wiring is still the baseline.

When I would consider it

I would consider Injex when:

• the same service graph is reused by API, CLI, workers, and tests;
• constructors already describe dependencies with type hints;
• tests need temporary external-service overrides;
• startup should catch wiring problems early;
• the team wants explicit wiring without a large DI framework.

Links

Repo: https://github.com/vshulcz/injex

Docs: https://vshulcz.github.io/injex/

Performance notes: https://vshulcz.github.io/injex/docs/performance.html

Compared to FastAPI Depends: https://github.com/vshulcz/injex/blob/main/docs/fastapi-depends.md

FastAPI lifespan example: https://github.com/vshulcz/injex/blob/main/examples/fastapi_lifespan.py