Graham Dumpleton's wrapture does testing and tracing from the same bindings

Graham Dumpleton, the author of the widely used wrapt monkey-patching library and the original author of the New Relic Python agent, released a new Python package called wrapture on 31 August, with the first announcement post on his blog. Ten follow-up tutorials have gone out almost daily since then. Simon Willison flagged the release on 11 September, saying he was "not sure why I've seen so little buzz about it" and calling wrapture "one of those Swiss Army Knife packages that, once mastered, will provide value against all sorts of problems for years to come".

The name is wrapt plus capture. Dumpleton writes that testing and tracing "look like different problems, but from where I sat they wanted the same thing". unittest.mock answers every method call, verifies nothing on its own, and records a flat list of calls with no return values and no sense of what called what. Instrumentation libraries used for tracing, by contrast, record real calls but do not let a test assert against them. Wrapture is his attempt to serve both jobs from one set of bindings.

Wrap instead of replace

Every wrapture binding names a location in code, a method of a class or a function in a module, and installs a wrapt wrapper around the real callable when it is applied. Unless a test tells it otherwise, the wrapper is transparent: the real code runs, and wrapture sits in a position to watch the call, change it, or answer it instead of the real function. That means a test can assert against the actual calls a component makes, including internal ones between its own methods, without swapping the component out for a fake.

The same bindings can produce a timeline of calls with return values, arranged as a tree that follows the call graph rather than the flat list unittest.mock produces. Dumpleton has published separate tutorials on phased behaviour across calls, on recording calls for later inspection, and on patching attributes, dictionaries, and generators as well as callables.

Zero-code tracing and an OpenTelemetry export

Wrapture can also be configured from a separate TOML file, without editing the Python code it observes. Dumpleton's tutorial titled "Zero-code tracing with wrapture" describes turning tracing on for a live program from an external file, and the "OpenTelemetry export in wrapture" post shows how to send those traces into an OpenTelemetry collector. A companion package called wrapture-instrumentation includes pre-written bindings for aiohttp, Django, FastAPI, Flask, gRPC, httpx, requests, SQLAlchemy, SQLite3, Starlette, uvicorn, and about a dozen more standard-library and framework entry points.

The package is still alpha, released under BSD 2-Clause, and the GitHub repository holds 30 stars at the time Willison's post went out. In the introduction post Dumpleton says the code was "written by an AI under my direction", which is worth noting on a site whose whole argument is that AI-written code needs an eval suite before it is released: an author with two decades of experience in exactly this problem area is the eval suite here.

For a Python team, the practical decision is whether to keep unittest.mock and an OpenTelemetry instrumentation library as two separate dependencies, or move both jobs into one library whose author has thought about wrapping Python for twenty years. Alpha software is alpha software, but the potential of this design is high, and Willison highlighting it is the reason it will now get read.

Source

Simon Willison's note, Don't sleep on wrapture, pointing at Graham Dumpleton's Introducing wrapture and the tutorials that followed. The code is at GrahamDumpleton/wrapture.