How do you wire shared services into Typer commands?

[vshulcz]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the documentation, with the integrated search.
• I already searched in Google "How to X" and didn't find any information.
• I already read and followed all the tutorials in the docs and didn't find an answer.

Example Code

from dataclasses import dataclass
import typer

app = typer.Typer()

@dataclass(frozen=True)
class Settings:
    api_url: str
    token: str

class ApiClient:
    def __init__(self, settings: Settings):
        self.settings = settings

    def fetch_status(self) -> str:
        return f"connected to {self.settings.api_url}"

class UserRepository:
    def __init__(self, client: ApiClient):
        self.client = client

    def sync(self) -> str:
        return self.client.fetch_status()

class SyncUsersCommand:
    def __init__(self, repository: UserRepository):
        self.repository = repository

    def run(self) -> None:
        typer.echo(self.repository.sync())

def build_settings() -> Settings:
    return Settings(
        api_url="https://api.example.com",
        token="dev-token",
    )

def build_sync_users_command() -> SyncUsersCommand:
    settings = build_settings()
    client = ApiClient(settings)
    repository = UserRepository(client)
    return SyncUsersCommand(repository)

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

if __name__ == "__main__":
    app()

Description

I’m looking for guidance on the recommended Typer pattern for wiring shared services into commands.

In small CLI apps, creating objects directly inside each command is clear. The question starts when several commands share the same infrastructure: settings, API clients, repositories, and application services.

The example above uses a small factory function:
build_sync_users_command()

That works, but as the CLI grows it can lead to repeated setup code across commands. I’m trying to understand what Typer users usually prefer:

• one build_services() / build_container() function used by all commands;
• typer.Context / ctx.obj for shared objects;
• factories per command;
• module-level singletons;
• a DI container outside Typer;
• another pattern.

The goal is to keep Typer command functions thin: parse CLI arguments, get the command object, run it. I also want the application services to stay independent from Typer so they can be reused from tests, workers, or other entrypoints.

Operating System

macOS

Operating System Details

No response

Project Version

Not version-specific

Python Version

Not version-specific

Additional Context

This is an architecture / project-structure question, not a bug report.
I’m not asking Typer to provide a dependency injection system. I’m trying to understand the clean boundary between Typer command functions and application-level service wiring in larger CLI applications.

[sueun-dev]

Typer doesn't have per-arg injection like FastAPI's Depends, commands are just Click commands under the hood. so the clean split is: keep the real wiring in a plain build_services() that imports zero Typer, and build it once in @app.callback() onto ctx.obj. commands stay thin, pull the object, run it.

def build_services(settings=None):   # framework-agnostic, reuse anywhere
    settings = settings or Settings(...)
    return {"sync_users": SyncUsersCommand(UserRepository(ApiClient(settings)))}

@app.callback()
def main(ctx: typer.Context):
    ctx.obj = build_services()

@app.command()
def sync_users(ctx: typer.Context):
    typer.echo(ctx.obj["sync_users"].run())

ran it on typer 0.23.2: the CLI path works, and build_services() is callable straight from a test or worker with no Typer involved, so you swap fakes just by passing different settings. that keeps the services independent like you wanted. ctx.obj is per-invocation too, so you avoid module-global singletons.

[vshulcz]

The pattern I’m taking from this is:

• keep build_services() free of Typer imports;
• call it once in @app.callback();
• store the result in ctx.obj;
• keep commands thin: parse CLI input, get the command/service, run it;
• tests and workers call build_services() directly.

Something like:

def build_services(settings: Settings) -> Services:
    client = ApiClient(settings)
    repo = UserRepository(client)
    return Services(sync_users=SyncUsersCommand(repo))
    
@app.callback()
def main(ctx: typer.Context):
    ctx.obj = build_services(load_settings())
    
@app.command()
def sync_users(ctx: typer.Context):
    ctx.obj.sync_users.run()

That keeps Typer as the adapter layer, not the place where the service graph lives.

For a small CLI I’d keep plain factories. For a CLI that shares the same graph with FastAPI/workers/tests, I can see value in having one composition root or a tiny DI container around that graph.

[svlandeg]

Typer doesn't have per-arg injection like FastAPI's Depends

Just FYI - this is something we do have on our internal road map to work on for Typer 🎉

[vshulcz]

For Typer, I think even a small first-class pattern for this would help a lot.
The use case I keep running into is not full application DI inside commands, but keeping command functions thin while reusing the same service graph from:

• Typer commands;
• tests;
• workers;
• maybe a FastAPI app in the same project.

Something like per-command/per-invocation dependencies could make this cleaner, especially if the underlying services stay plain Python and Typer-specific code remains at the command boundary.

[vshulcz]

Big +1 on per-arg injection being on the roadmap - that'd be lovely.

For anyone landing here now, the @app.callback() + ctx.obj pattern holds up really well in practice, and the part that sold me on it is how cleanly it tests. The trick is to keep one framework-agnostic build_services() and let Typer be a thin adapter:

# services.py - knows nothing about Typer
def build_services(settings: Settings) -> Services:
    # construct repos/clients/use-cases once
    return Services(...)

# cli.py
@app.callback()
def main(ctx: typer.Context):
    ctx.obj = build_services(load_settings())

@app.command()
def register(ctx: typer.Context, email: str):
    ctx.obj.register_user.execute(email)   # command stays thin

Because build_services() is plain Python, the same graph runs in a worker or a script with no Typer involved - and tests don't need Typer's runtime at all:

def test_register():
    services = build_services(test_settings())
    services.register_user.repo = FakeRepo()   # or build with fakes
    services.register_user.execute("ada@example.com")

And when you do want to exercise the CLI end to end, CliRunner + a callback that swaps in a test ctx.obj keeps it isolated:

runner = CliRunner()
app_under_test = build_app(services=build_services(test_settings()))
result = runner.invoke(app_under_test, ["register", "ada@example.com"])

The mental rule that's served me: Typer owns argument parsing and I/O; the application owns the service graph. Keeps commands thin and the wiring reusable across CLI, workers, and tests without duplicating setup.