Metadata-Version: 2.4
Name: logbrew-django
Version: 0.1.0
Summary: Django integration for capturing LogBrew request spans and exceptions.
Author: LogBrew
License-Expression: MIT
Project-URL: Repository, https://github.com/LogBrewCo/sdk
Keywords: logbrew,observability,django,middleware,logs
Classifier: Development Status :: 3 - Alpha
Classifier: Framework :: Django
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Typing :: Typed
Requires-Python: >=3.11
Description-Content-Type: text/markdown
Requires-Dist: Django>=5.2
Requires-Dist: logbrew-sdk==0.1.0

# logbrew-django

Django integration for capturing LogBrew request spans and exceptions with the public Python SDK.

## Install

```bash
python3 -m pip install logbrew-sdk logbrew-django
python3 -m logbrew_django.examples --help
python3 -m logbrew_django.examples --list
python3 -m logbrew_django.examples readme-example
python3 -m logbrew_django.examples real-user-smoke
python3 -m logbrew_django.examples
```

The package is typed, ships `py.typed`, depends on the core `logbrew-sdk`, and keeps Django as a normal framework dependency instead of owning the user's project layout.

## Example

```python
# settings.py
MIDDLEWARE = [
    "logbrew_django.LogBrewDjangoMiddleware",
    *MIDDLEWARE,
]
```

```python
# app startup code
from logbrew_django import configure_logbrew
from logbrew_sdk import LogBrewClient, RecordingTransport

client = LogBrewClient.create(
    api_key="LOGBREW_API_KEY",
    sdk_name="logbrew-django",
    sdk_version="0.1.0",
)
transport = RecordingTransport.always_accept()
configure_logbrew(
    client=client,
    transport=transport,
    span_id_factory=lambda: "b7ad6b7169203331",
)
```

`LogBrewDjangoMiddleware` records successful requests as span events, records unhandled view exceptions as issue plus error-span events, and flushes through the configured transport after each response. If no transport is provided, events stay queued on the core client so the project can flush them itself.

When an incoming request has a valid W3C `traceparent` header, request capture continues that trace by using the incoming `traceId` and parent span id while creating a fresh child span id. Missing or malformed `traceparent` headers keep the existing synthetic request span behavior so bad client headers do not break the project. Automatic metadata uses the request path without query text. Use `span_id_factory` only when tests need deterministic child span ids.

By default, transport failures do not break the Django response path. Set `raise_flush_errors=True` in test environments when you want misconfigured transport behavior to fail loudly.

Use a clearly fake placeholder like `LOGBREW_API_KEY` in local examples and tests.
