Fresh install broken: pydantic-ai 0.0.37 imports removed opentelemetry._events (all patchflows fail as 'not found')

[sam-fakhreddine]

Summary

A clean pip install patchwork-cli (0.0.124) produces an environment where every patchflow fails to load. The user-facing error is misleading — it says the patchflow was not found — but the real cause is an ImportError during flow import:

ModuleNotFoundError: No module named 'opentelemetry._events'

Environment

• patchwork-cli 0.0.124
• pydantic-ai / pydantic-ai-slim 0.0.37 (pinned by patchwork-cli)
• opentelemetry-api — whatever the resolver picks (currently ≥1.30.0)
• Python 3.12.11, fresh venv

Reproduction

python -m venv env && . env/bin/activate
pip install patchwork-cli
patchwork GenerateDocstring base_path=./somecode client_base_url=http://localhost:8080/v1 openai_api_key=x model=some-model

Result:

[red] Patchflow GenerateDocstring not found in deque(['patchwork.patchflows'])

Root cause

pydantic-ai-slim==0.0.37 (pinned transitively by patchwork-cli) imports opentelemetry._events unconditionally in pydantic_ai/messages.py:

from opentelemetry._events import Event

but declares only opentelemetry-api>=1.28.0 with no upper bound. The experimental opentelemetry._events module is not present across that whole range — it exists in ~1.26–1.29 and is gone in current releases (≥1.30.0). So a fresh resolve pulls a too-new opentelemetry-api, pydantic_ai fails to import, and every patchflow becomes unimportable.

Confirmed empirically:

• opentelemetry-api==1.29.0 → import opentelemetry._events works, patchflows load.
• opentelemetry-api>=1.30.0 → ModuleNotFoundError: No module named 'opentelemetry._events'.

Workaround

pip install 'opentelemetry-api==1.29.0' 'opentelemetry-sdk==1.29.0'

Requests

1. Constrain the dependency so a fresh install is not broken — e.g. pin opentelemetry-api<1.30 (or ==1.29.*), or bump pydantic-ai to a release that guards / no longer requires opentelemetry._events.
2. Surface flow ImportErrors instead of masking them. The real ModuleNotFoundError is swallowed and reported as Patchflow <name> not found in deque([...]), which sends people down the wrong path (checking flow names / spelling) instead of the actual dependency problem. Logging the underlying import exception when a registered flow fails to import would save a lot of debugging.

For what it's worth, once the opentelemetry pin is applied everything works great — drove GenerateDocstring against a local OpenAI-compatible endpoint and it wrote correct docstrings end-to-end. Thanks for the tool.