LLM 0.33's httpx2 switch broke plugins that never declared httpx
Simon Willison's llm-tools-datasette 0.1.1 fixes a plugin broken by LLM 0.33's move to httpx2. The cause is a familiar packaging trap: importing a library you never declared as a dependency.
By TRAGenX Desk
What happened
Simon Willison released llm-tools-datasette 0.1.1, a small plugin for his LLM command-line tool. In the release note, he explains that when he switched LLM over to httpx2 in LLM 0.33, he forgot this would break any plugin that used httpx without directly depending on it. llm-tools-datasette was one of them, and 0.1.1 is the fix.
The release is minor, but it shows a failure mode that agentic tooling invites. Tool plugins are small, quick to write, and tend to lean on whatever the host environment already provides.
Why undeclared dependencies break
A Python package can import httpx and work fine as long as something else in the environment installed it. Here, that something was the host application. The plugin never listed httpx in its own metadata, so nothing recorded that it needed the library. When the host changed its HTTP client, the plugin's assumption stopped holding.
Neither side made an obvious mistake in isolation. The host was free to change its internals. The plugin worked in every environment where it had been tried. The breakage sits in the gap between what the plugin imports and what it declares.
What builders should take from it
- Declare what you import. If your code does
import X, thenXbelongs in your package's dependencies, even if your host already pulls it in today. - Treat the host's dependency tree as private. A host is not promising to keep any particular library installed for you.
- Test against new host releases. A plugin smoke test run on each host release would catch this kind of break quickly.
- Keep the fix small. Here, the remedy is a patch release, 0.1.1, and the plugin can use the newer host from then on.
Why this matters for agent and trading tooling
LLM tool plugins give a model access to data and actions, such as querying a database through Datasette. The more agent tooling you assemble from small plugins, the more of your stack rests on unstated assumptions about the host. In trading and fintech systems, a plugin that silently fails to import, or a tool that disappears after an upgrade, can leave an automated workflow without the capability it expects.
That risk is mostly an engineering-hygiene one rather than an AI one. Pinned and declared dependencies, version-bump testing, and explicit failure when a tool can't load are the same practices that keep conventional services dependable. They matter more when the code is AI-assisted and written quickly, because speed is when an implicit dependency slips through.
What we don't know
The release note is brief. It doesn't say how many other plugins were affected, and we haven't verified anything beyond what it states. If you run LLM plugins, check each plugin's release notes after upgrading to LLM 0.33 or later.
FAQ
Frequently asked questions
- What does llm-tools-datasette 0.1.1 fix?
- According to Simon Willison's release note, LLM 0.33 switched to httpx2, which broke plugins that used httpx without directly depending on it. llm-tools-datasette was one of those plugins, and 0.1.1 fixes it.
- Why did a host library change break a plugin?
- The plugin imported httpx without declaring it as its own dependency, so it relied on the host to provide it. When the host changed its HTTP library, that assumption failed.
- How can I avoid this in my own plugins?
- List every library your code imports directly in your package's declared dependencies, and run a basic import and smoke test against each new release of the host application.
Sources
- llm-tools-datasette 0.1.1 — Simon Willison
- LLM documentation — Simon Willison