dibox 0.1.9

Async-native dependency injection framework based on type hints

DIBox

---

⚠️ Project Status: Early Development

This library is in its early stages. The design and API are not yet fully established and may change significantly in future releases. Feedback, suggestions, and contributions are very welcome!

---

Async-native dependency injection framework based on type hints.

• Installation
• What is DIBox?
• Key Features
• QuickStart
  • 1. Define your application as usual
  • 2. Wire and Run
• Usage Guide
  • Using Decorators for Injection
  • Resource Lifecycle
    • Binding Patterns
    • Binding Interfaces & Instances
    • Factory Functions
    • Named dependencies
    • Dynamic Predicate-Based Binding
    • Strict Mode
  • Binding Modules
    • Organizing bindings by feature
    • Reusing modules across contexts
    • Overriding bindings for tests
    • Resolution order
• Why use DIBox?
  • The Power of Auto-Wiring
  • Comparison with Other Frameworks
    • vs. Manual Dependency Injection
    • vs. dependency-injector
    • vs. Injector
    • vs. Punq
    • vs. Dishka
    • vs. FastAPI's Depends
• Contributing

Installation

pip install dibox

Requires Python 3.11+.

What is DIBox?

DIBox is an async‑native dependency injection container that uses standard Python type hints to build and manage your service dependency graph automatically. The core philosophy is to remove factory and wiring boilerplate so you can focus on application logic.

DIBox resolves, instantiates, and injects dependencies by following naturally defined type hints in constructors or entry points. It also orchestrates asynchronous startup and safe teardown for resources like database connections, credential loaders, or HTTP clients without extra glue code.

Key Features

• Auto-Wiring: Type-annotated constructors are resolved and injected automatically — no factory boilerplate.
• Async‑Native: Async factories, async context managers, and async lifecycle hooks all work out of the box.
• Lifecycle Management: Resources start and clean up automatically. DIBox recognizes context managers, generator factories and start/close conventions.
• Context-aware @inject: Decorate at import time, resolve at call time from the active container — no container reference at the call site.
• Flexible Bindings: Interfaces, instances, sync/async factories, named dependencies, and predicate-based bindings.
• Strict Mode: DIBox(strict=True) requires all types to be explicitly registered — recommended for production.
• Non‑Invasive: Works with any class using type hints — third-party SDKs, dataclasses, attrs — no wrappers or base classes required.
• Modular: Group bindings into reusable BindingBox modules. Compose, override, and share across workers, tests, and entry points.
• Typed API: Fully type-annotated — works seamlessly with type checkers and IDE autocompletion.

QuickStart

DIBox requires almost no setup. Define your classes as usual—whether you use standard Python classes with __init__, dataclasses, or attrs models.

1. Define your application as usual

Just use type hints to declare dependencies, no DI boilerplate needed.

import asyncio

class Credentials:
    def __init__(self, username: str):
        self.username = username

class Database:
    def __init__(self, creds: Credentials):
        self.creds = creds

class Service:
    def __init__(self, db: Database):
        self.db = db

    async def start(self):
        await asyncio.sleep(0.05)  # simulate warm-up
        print("Service started")

    async def close(self):
        await asyncio.sleep(0.05)  # simulate cleanup
        print("Service closed")

    def run(self):
        print("Service is running...")

DIBox detects and manages lifecycle hooks automatically. The Service class below uses start()/close() — one of several supported patterns, covered in full in Resource Lifecycle.

2. Wire and Run

Only bind what DIBox can't infer — here, Credentials because it's a raw value with no type-hinted constructor to follow.

from dibox import DIBox

box = DIBox()
box.bind(Credentials, Credentials(username="admin"))  # raw value: bind it explicitly

async def main():
    async with box:                           # activate container; start() called on managed resources
        service = await box.provide(Service)  # resolve the graph: Credentials → Database → Service
        service.run()
    # close() called automatically on exit

asyncio.run(main())

For framework entry points — FastAPI routes, CLI commands — @inject is the idiomatic choice. Decoration happens at module load time; resolution happens at call time from whichever container is active:

from dibox import inject, Injected

@inject
async def main(service: Injected[Service]):  # Injected[T] marks the parameter for injection
    service.run()

async def run():
    async with box:   # makes box the active container for this async context
        await main()  # service is resolved and injected automatically

asyncio.run(run())

Next step: The quickstart uses DIBox's default permissive mode — unbound concrete types are auto-wired from their constructor. For production, DIBox(strict=True) is recommended. See Strict Mode.

Usage Guide

Using Decorators for Injection

Decorators allow injecting dependencies into entry points — API routes, CLI commands, Lambda handlers — without cluttering call sites. A key feature: @inject rewrites the function's runtime signature, removing Injected[T] parameters. Frameworks that inspect signatures at import/routing time only see your "real" parameters (path/query args, request objects, etc.).

DIBox offers three options in increasing order of explicitness.

1. @inject — context-based (idiomatic)

The recommended default. Apply @inject at module level — no container reference needed at decoration time. At call time, it resolves dependencies from whichever DIBox is active via async with box:. Because the active container is stored in a ContextVar, it is isolated per async task and per OS thread — there is no process-wide global, and concurrent requests each see their own container.

from dibox import inject, Injected

@inject
async def get_report(report_id: str, svc: Injected[ReportService]) -> Report:
    return await svc.fetch(report_id)

This pairs naturally with framework lifespans. The async with box: that starts your container also establishes the injection context for all @inject-decorated functions:

from contextlib import asynccontextmanager
from fastapi import FastAPI
from dibox import DIBox, inject, Injected

box = DIBox()

@asynccontextmanager
async def lifespan(app: FastAPI):
    async with box:
        box.bind(Database, await create_database())
        yield  # app runs here; @inject resolves from box

app = FastAPI(lifespan=lifespan)

@app.get("/report/{report_id}")
@inject
async def get_report(report_id: str, db: Injected[Database]):
    return await db.fetch_report(report_id)

FastAPI sees get_report(report_id: str) — the injected db parameter is invisible to the framework.

2. @box.inject — explicit container

When you want injection tied to a specific container instance rather than the active context, use @box.inject. Unlike @inject, it ignores the ContextVar entirely — the container is captured at decoration time and always used, regardless of which container is active at call time.

local_box = DIBox()

@local_box.inject
async def specific_handler(service: Injected[Service]):
    ...

Useful when you have multiple concurrent containers, in integration tests where you want injection to be explicit, or when you simply prefer the container reference visible at the call site.

For advanced use cases (custom container resolution strategies, enforcing architectural layers), the underlying Injector class is available directly. It accepts either a container instance or a container_resolver callable and exposes the same .inject decorator.

Imperative entrypoints (planned)

The entrypoints ADR also proposes DIBox.call() and DIBox.partial() for direct execution use cases (injecting by inspecting the function signature without Injected[...] markers). These APIs are not implemented yet (currently, DIBox.call() raises NotImplementedError).

Today, the supported imperative API is await box.provide(T) (and box.get(T) for already-created instances).

Resource Lifecycle

DIBox acts as the coordinator for resource startup and teardown. All managed instances are started when first provided and torn down in reverse order (LIFO) when the container exits:

async with box:
    setup_bindings(box)
    await run()
# All managed resources are torn down here, in reverse order of creation

Class-based resources

For class instances, DIBox detects lifecycle hooks automatically after construction. The detection priority is:

1. Async context manager (__aenter__/__aexit__)
2. Sync context manager (__enter__/__exit__)
3. start/close/aclose convention — sync or async, detected by name

class DatabaseClient:
    async def start(self):
        self.conn = await engine.connect()

    async def close(self):
        await self.conn.close()

# DIBox calls start() after construction and close() on container exit
db = await box.provide(DatabaseClient)

Factory-based teardown

When setup and teardown belong together, generator factories keep them co-located. DIBox injects the yielded value and runs the post-yield code when the container exits.

from contextlib import contextmanager, asynccontextmanager

@contextmanager
def create_db_session(engine: Engine) -> Iterator[Session]:
    session = engine.connect()
    try:
        yield session
    finally:
        session.close()

@asynccontextmanager
async def create_http_client(settings: Settings) -> AsyncIterator[httpx.AsyncClient]:
    async with httpx.AsyncClient(base_url=settings.api_url) as client:
        yield client

box.bind(Session, create_db_session)
box.bind(httpx.AsyncClient, create_http_client)

Plain generator functions (without the decorator) are also accepted — DIBox wraps them automatically — but the explicit decorator is recommended for clarity.

Binding Patterns

DIBox shines when you need precise control over object creation. You can mix and match these patterns to handle everything from cloud clients to dynamic configuration.

Binding Interfaces & Instances

You can bind a base class to a concrete implementation or a specific instance.

from dibox import DIBox

box = DIBox()

azure_credentials = DefaultAzureCredential()
# Any request for TokenCredential will receive azure_credentials object
# box.bind(TokenCredential, azure_credentials) works too!
box.bind(TokenCredential, instance=azure_credentials)
# Or bind an interface to a concrete class
box.bind(DatabaseInterface, CosmosDBDatabase)

Factory Functions

Sometimes a simple constructor isn't enough—you may need asynchronous setup (fetching secrets, warming a client) or a third‑party initialization step. Bind the target type to a factory function—sync or async.

Key Feature: DIBox inspects your factory’s signature, auto‑injects its parameters, and if it is async it awaits it automatically before wiring downstream dependencies.

# Async factory: simulate secret fetch / remote handshake
async def create_cosmos_client(settings: Settings) -> CosmosClient:
    await asyncio.sleep(0.05)  # simulate IO
    return CosmosClient(url=settings.url, key=settings.key)

# Sync factory depending on the async-created client
def create_orders_container(client: CosmosClient) -> OrderContainer:
    return OrderContainer(client.get_container("orders"))

# Bind factories (DIBox auto-injects Settings, awaits async factory)
box.bind(CosmosClient, create_cosmos_client)
# to be more explicit, you can use the factory= keyword argument:
box.bind(OrderContainer, factory=create_orders_container)

order_container = await box.provide(OrderContainer)  # auto sequence:
# Settings -> await create_cosmos_client -> create_orders_container

Named dependencies

If you need multiple instances of the same type (like two different storage containers), use the name parameter. DIBox matches this binding to the argument name.

box.bind(ContainerClient, "users", factory=create_users_container)
box.bind(ContainerClient, "orders", factory=create_orders_container)

class DataService:
    def __init__(self, users: ContainerClient, orders: ContainerClient):
        self.users = users    # Injected with "users" binding
        self.orders = orders  # Injected with "orders" binding

# Requesting DataService will get both ContainerClients injected correctly
data_service = await box.provide(DataService)

Dynamic Predicate-Based Binding

For repeatable patterns, you can use a predicate function to match types dynamically. This is useful for generic loaders or handlers. The factory function can also receive the requested type as a parameter for more context-aware creation.

def load_settings(t: type) -> object:
    # Load settings based on type t
    ...

# Bind ANY type ending in 'Settings' to the 'load_settings' function
box.bind(lambda t: t.__name__.endswith("Settings"), load_settings)

# Now requesting AppSettings or DBSettings will use load_settings automatically
app_settings = await box.provide(AppSettings)
db_settings = await box.provide(DBSettings)

Strict Mode

By default, DIBox operates in permissive mode: any concrete type with a type-annotated constructor is auto-wired without an explicit bind(). This is the fastest way to get started.

For production applications, DIBox(strict=True) is recommended. It enforces that all dependencies must be explicitly registered, which prevents the container from silently auto-constructing a type that was meant to be configured. This makes dependency errors loud and immediate, preventing unexpected failures deep in a dependency chain.

box = DIBox(strict=True)

box.bind(AppConfig, instance=load_config())          # external value — always explicit
box.bind(StorageClient, S3StorageClient)             # interface → implementation
box.bind_many(Database, AuthService, ReportService)  # self-bind concrete services

bind(T) self-binds a type (equivalent to bind(T, T)). bind_many(...) registers several at once, turning strict mode's requirement into a compact declaration of what the container owns.

Migrating from permissive to strict is straightforward: switch DIBox() to DIBox(strict=True) and add bind(T) for each concrete service that was being auto-wired. For most apps this is a handful of lines with an immediate payoff in predictability.

Binding Modules

A BindingBox is a portable set of binding rules. Define it once, compose it wherever that context is needed — a pipeline stage, a background worker, a CLI command, a test.

Organizing bindings by feature

# storage/deps.py
from dibox import BindingBox

storage_bindings = BindingBox()
storage_bindings.bind(StorageClient, S3StorageClient)
storage_bindings.bind(BlobIndex)

# ml/deps.py
from dibox import BindingBox

ml_bindings = BindingBox()
ml_bindings.bind(ModelRegistry)
ml_bindings.bind(Classifier)

# main.py
from dibox import DIBox
from storage.deps import storage_bindings
from ml.deps import ml_bindings

async with DIBox() as box:
    box.bind(AppConfig, instance=load_config())  # raw config — bound directly
    box.add_bindings(storage_bindings)
    box.add_bindings(ml_bindings)

    classifier = await box.provide(Classifier)

Reusing modules across contexts

A BindingBox holds binding rules, not live resources — it's a plain Python object, independent of any specific container. The same module can be composed into different containers in different contexts without duplication, and because it carries no open connections or handles, it can be imported in any process. This makes it the natural contract between an orchestrator and its workers.

To make this concrete, here's a pipeline stage running as a Ray remote function — a function dispatched to a separate worker process by the framework.

Without modules, every worker duplicates the same setup:

# pipeline/stages.py — defined once, importable from anywhere
enhance_bindings = BindingBox()
enhance_bindings.bind(GPUContext)
enhance_bindings.bind(Enhancer)

@ray.remote  # runs this function in a separate worker process
def enhance_v1(config: AppConfig, tiles: list[bytes]) -> list[bytes]:
    async def _run() -> list[bytes]:
        box = DIBox()
        box.bind(AppConfig, instance=config)
        box.bind(GPUContext)  # repeated in every worker
        box.bind(Enhancer)    # and again here
        async with box:
            enhancer = await box.provide(Enhancer)
            return await enhancer.enhance(tiles)
    return asyncio.run(_run())

With modules, the worker declares what context it needs in one line:

@ray.remote  # runs this function in a separate worker process
def enhance_v2(config: AppConfig, tiles: list[bytes]) -> list[bytes]:
    async def _run() -> list[bytes]:
        box = DIBox()
        box.bind(AppConfig, instance=config)
        box.add_bindings(enhance_bindings)  # same module — no duplication
        async with box:
            enhancer = await box.provide(Enhancer)
            return await enhancer.enhance(tiles)
    return asyncio.run(_run())

The same module also works in-process — for example, as a scoped stage container in the main pipeline:

async with DIBox(parent=run_box) as stage:
    stage.add_bindings(enhance_bindings)
    enhancer = await stage.provide(Enhancer)
    tiles = await enhancer.enhance(tiles)
# GPUContext released when the stage exits

Overriding bindings for tests

When modules are composed, the last registered wins. This is useful for integration tests: register the production modules first, then add a module with fakes on top without touching the original module.

# tests/fakes.py
fake_storage = BindingBox()
fake_storage.bind(StorageClient, InMemoryStorageClient)  # no S3 in tests

# tests/test_classifier.py
async def test_classifier():
    async with DIBox() as box:
        box.bind(AppConfig, instance=test_config)
        box.add_bindings(ml_bindings)      # real ML module
        box.add_bindings(fake_storage)     # replaces S3StorageClient — last wins

        classifier = await box.provide(Classifier)
        ...

Resolution order

When the same type is bound in multiple places, last registered wins: container's own bind() calls always take highest precedence, then modules in reverse registration order. If no binding matches at all, DIBox falls back to using the requested type as its own factory — this is what makes await box.provide(SomeService) work without an explicit box.bind(SomeService). This fallback is permissive mode behavior and can be disabled with DIBox(strict=True); see Strict Mode.

Why use DIBox?

The Power of Auto-Wiring

Dependency Injection (DI) decouples your high-level business logic from low-level implementation details (like database drivers or API clients). This makes your code modular and effortless to test—you can easily swap a real database for a mock during unit tests.

However, traditional DI often trades one problem for another: Dependency Hell. You end up writing hundreds of lines of "glue code" just to instantiate your service graph.

DIBox's standout feature is its ability to automatically resolve and inject dependencies based on type hints. It inspects your classes, sees what they need, and assembles the puzzle for you. You stop writing factories and start writing features.

Comparison with Other Frameworks

There are many great DI frameworks for Python out there. Here is why you might choose DIBox:

• vs. Manual Dependency Injection

  • The Problem: Manually instantiating services (Service(Database(Config()))) works for small scripts but becomes tedious and error-prone as your app grows.
  • The DIBox Way: DIBox eliminates boilerplate factory code by auto-wiring based on type hints. You write less glue code and focus on your business logic.

• vs. dependency-injector

  • The Approach: Dependency Injector is a powerful, feature-rich framework that uses a declarative style. You explicitly define Container classes and Providers for every component.
  • The DIBox Difference: DIBox takes a more implicit, convention-over-configuration approach. You rarely need to define explicit providers—most wiring is automatic based on type hints. This makes it particularly seamless when integrating Third-Party SDKs (like Azure SDK or Boto3). You can simply bind an abstract class (e.g., TokenCredential) to a concrete instance, and DIBox automatically injects it into the SDK client's constructor without needing wrapper classes or complex factory providers.

• vs. Injector

  • The Approach: Injector encourages a structured configuration style using explicit Module classes and Provider methods. While it supports type hints, it often relies on the @inject decorator to explicitly mark constructors for injection—particularly when you need to mix injectable and non-injectable arguments or when auto_bind is disabled.
  • The DIBox Difference: DIBox favors a zero-boilerplate approach. It does not require separate Module definitions to wire your graph; it defaults to auto-wiring based on existing type hints. For lifecycle concerns, DIBox automatically detects common async/sync resource hooks (__aenter__/__aexit__, start()/close(), context managers) and runs them for you. Injector provides lifecycle and scoping control through its own mechanisms and explicit patterns; DIBox emphasizes convention and automatic detection for asynchronous workloads.

• vs. Punq

  • The Approach: Punq is a minimalistic DI container that shares our philosophy of simplicity and auto-wiring. It relies heavily on explicit bindings and does not support advanced features like async lifecycle management or predicate-based bindings.
  • The DIBox Difference: DIBox adds async lifecycle management and a few more binding patterns while keeping the same “type-hints-first” feel.

• vs. Dishka

  • The Approach: Dishka is a powerful DI framework built around a first-class scoping system and explicit Provider classes. This gives you fine-grained control over dependency lifetimes and structure, with ready-made integrations for many popular frameworks.
  • The DIBox Difference: DIBox offers a simpler, more minimal API. Instead of Provider classes, DIBox auto-wires any class with a type-annotated constructor, so you only bind what can't be inferred (e.g., interfaces, raw values). This convention-over-configuration approach reduces boilerplate for common cases. DIBox also offers unique features like predicate-based binding and named-argument injection. However, Dishka currently has a more mature feature set, including a robust scoping model and a dependency graph visualizer. If those features are critical for your project right now, Dishka is an excellent choice. Scopes are on the DIBox roadmap.

• vs. FastAPI's Depends

  • The Approach: FastAPI revolutionized Python development with its intuitive, type-hint-based dependency injection. It is the primary inspiration behind DIBox. FastAPI's dependency injection system is tightly integrated with its web framework. It uses the Depends marker to declare dependencies in path operation functions.
  • The DIBox Difference: While FastAPI's DI is excellent for web applications, DIBox is a standalone framework that can be used across any Python application. It extends the same principles to a broader context, including CLI apps, serverless functions, and background services. DIBox also adds advanced features like async lifecycle management and predicate-based bindings that go beyond FastAPI's capabilities.

Contributing

The project is in early stages, and contributions are welcome! Please contact me (Alex Z.) via GitHub issues, LinkedIn or email for any questions, suggestions, or contributions. The source code is hosted both on GitHub (https://github.com/mxAlexZ/dibox) and GitLab (https://gitlab.com/AlexZee/dibox). The actual development happens on GitLab, while GitHub is used for better visibility.