llm-tools-datasette 0.1.1 Fixes Dependency Issue, Raising Concerns About Plugin Ecosystem Stability

The Hidden Plugin Dependency Risks Behind a Minor Version Update

Simon Willison has released version 0.1.1 of llm-tools-datasette, fixing a compatibility issue caused by the LLM core library switching its HTTP client. What looks like a routine patch release actually exposes the fragility of the plugin ecosystem in the AI toolchain—when underlying dependencies change, plugins that rely on them can silently break.

According to the release notes, the root cause is that LLM version 0.33 switched its HTTP client to httpx2. When migrating, the author overlooked one thing: plugins that directly use the https module without explicitly declaring it as a dependency will break due to changes in the underlying library. llm-tools-datasette is one of the affected plugins, and version 0.1.1 completes the fix.

Why Plugins Can "Silently Break"

The Trap of Implicit Dependencies

In the Python ecosystem, plugins often directly import standard library or indirectly depended-upon modules without declaring these dependencies in their package metadata. llm-tools-datasette uses https but did not list it as a direct dependency. When LLM 0.33 migrated its internal implementation from the old HTTP client to httpx2, the availability of https changed, and the plugin broke as a result.

This kind of implicit dependency is especially dangerous in fast-iterating AI toolchains. Developers often assume by default that the underlying library will always provide a certain module, but the maintainers of the underlying library have the right to adjust internal implementations. Once a change occurs, both plugin authors and users may be caught off guard.

Explicit Dependency Declaration and Python Packaging Metadata: In Python, the dependencies a package declares (for example, dependencies = [...] in pyproject.toml) determine which packages pip will pull during installation and the range of version constraints. Standard library modules (such as http.client) do not need to be declared, but if a plugin obtains a module indirectly through a third-party package without listing it as a dependency, that creates an "implicit dependency." When running pip or build tools, the dependency resolver only checks explicitly declared constraints, so implicit dependencies are neither installed nor checked for version compatibility. Once the upstream package that indirectly provides the module upgrades or removes it, the code will not throw an ImportError until runtime. Therefore, writing every actually imported third-party module into the metadata and auditing with pip check, importlib.metadata, or static scanning tools (such as deptry) is the standard way to discover implicit dependencies.

The Significance of Timely Fixes

Although version 0.1.1 only fixes the dependency issue, its timely release prevents users from encountering unexpected errors when using llm-tools-datasette to query Datasette data. For LLM users who rely on this plugin for data exploration, this is a necessary stability patch.

The Meaning of Semantic Versioning and Patch Versions (0.1.1): According to the Semantic Versioning (SemVer) convention, in the version number major.minor.patch, an increment to the patch version usually indicates that it contains only backward-compatible bug fixes and introduces no new features or breaking changes. llm-tools-datasette going from 0.1.0 to 0.1.1 precisely shows that the fix only targets runtime errors caused by dependencies and does not change the plugin's external interface. For users, this means the upgrade risk is very low; for installation environments that rely on automatic version resolution, a constraint of ≥0.1.0 will automatically include 0.1.1 in the selectable range. However, note that SemVer is only a community convention, not a mandatory rule, and when the underlying core library replaces internal implementations in a minor version (such as LLM 0.33), it can also indirectly break plugins—which is exactly the source of this issue.

Implications for the AI Tool Ecosystem

Plugin Developers Should Explicitly Declare Dependencies

This incident serves as a reminder to plugin developers: any module imported in code should have its dependency explicitly declared in pyproject.toml or setup.py. Even if a module is currently provided indirectly by the standard library or another package, explicit declaration can expose problems early when underlying changes occur, rather than waiting until runtime to report an error.

Core Library Changes Need to Be More Cautious

For core libraries like LLM that are depended on by a large number of plugins, when switching underlying implementations (such as the HTTP client), maintainers can consider highlighting potential impacts more prominently in the changelog or providing a transition period. The robustness of the plugin ecosystem depends on the stability of the contract between the core library and plugins, and implicit dependencies are precisely the most ambiguous part of that contract.

Technical Background of the HTTP Client Switch (from the Old Client to httpx2): HTTP client libraries in the Python ecosystem (such as requests, httpx, and aiohttp) differ in connection pooling, default timeout values, proxy handling, and synchronous/asynchronous interfaces. Core libraries often switch HTTP clients to gain asynchronous support, better connection reuse, or more unified exception types. But switching changes error types (for example, httpx's HTTPStatusError differs from requests' RequestException), default timeout behavior, and TLS configuration. If dependent parties write code according to the old client's exceptions or interfaces, it may break. For libraries like LLM that are widely depended on by plugins, releasing such changes in a minor version requires clearly listing the affected interfaces and migration methods in the changelog; otherwise, plugin authors will find it difficult to notice them immediately.

How Users Should Respond

When ordinary users encounter a plugin that suddenly stops working, they can first check whether the core library has just been upgraded and see whether a new version of the plugin has been released. Small version fixes like llm-tools-datasette are usually available soon after release, and timely updates can restore functionality.

Basic Process for Troubleshooting Plugin Failures: When a plugin suddenly becomes unavailable, you can first run pip list to check the versions of the core library and the plugin and confirm whether there has been a recent upgrade; then use pip check to check for dependency conflicts among installed packages. If the problem appears after an upgrade, you can first try rolling the core library back to the previous usable version (for example, pip install 'llm==0.32.*') to confirm causality; then check the plugin repository's issues and release records to confirm whether a corresponding fix version exists. For tools managed with uv, pipx, or virtual environments, locking version files (such as uv.lock) can prevent automatic upgrades from introducing unexpected changes and is an effective means of isolating such risks.

Conclusion

The release of llm-tools-datasette 0.1.1 is not complicated in itself, but it reflects a common problem in the AI toolchain: implicit dependencies can cause plugins to silently break when underlying changes occur. As the LLM ecosystem has more and more plugins, the standardization of dependency management will directly affect the reliability of the entire toolchain. For developers, explicitly declaring dependencies is the lowest-cost defense; for core library maintainers, transparency during changes is equally important.