ci: fix Python version mismatch and add Python 3.14 to matrix

[adityamehra]

Problem

CI jobs were silently running under the wrong Python interpreter — a job labeled Python 3.10 would execute with Python 3.12 (Ubuntu default) or Python 3.14 (macOS default). A validation step was added to assert the active interpreter matched the matrix target; every non-default version failed.

Additionally, Python 3.14 install jobs on macOS were hitting the 30-minute timeout due to source compilation of a C++ dependency.

Root-cause chain

1 — virtualenv >= 20.33 ignores poetry env use (Poetry 2.1.3)

actions/setup-python@v6 with cache: "poetry" internally calls poetry env use . In Poetry 2.1.3 + virtualenv ≥ 20.33 this call is silently ignored: the venv is always created with the runner's ambient Python (3.12 on Ubuntu, 3.14 on macOS). The resulting wrong-Python venv is then written to the cache under a key named for the matrix Python (e.g. …-3.10-…).

Evidence: only the jobs whose matrix Python matched the runner default passed — Python 3.12 on Linux and Python 3.14 on macOS.

2 — Poisoned cache survives even after the Poetry fix

Once Poetry was upgraded to 2.4.1 (which correctly handles virtualenv), the stale 3.12-in-a-3.10-labelled venv was still being restored from cache. Poetry matches cached venvs by name, not by the actual Python binary inside, so it reused the corrupted entry without complaint.

3 — grpcio 1.74.0 has no cp314 wheels

opentelemetry-exporter-otlp → opentelemetry-exporter-otlp-proto-grpc pulls in grpcio with only a loose lower bound (>=1.63.2). On a cold cache, pip found no pre-built cp314 wheel for grpcio 1.74.0 and compiled the C++ library from source — ~20 min on macOS arm64, exceeding the 30-min job timeout.

Changes

poetry==2.1.3 → poetry==2.4.1 — core fix

Poetry 2.1.4 added virtualenv<20.33 as a temporary workaround. Poetry 2.4.1 re-enabled virtualenv>=20.33 after the underlying virtualenv bug was fixed upstream. Upgrading to 2.4.1 resolves the root cause cleanly.

cache-dependency-path: "pyproject.toml" → "poetry.lock"

Changing the cache-dependency-path produces a new cache key, evicting all poisoned venvs written under the old Poetry version. poetry.lock is also a better cache signal: it invalidates whenever any transitive dependency is updated, not only when a direct constraint changes.

Removed id: setup-python and Configure Poetry Python step

These were scaffolding added to work around the poetry env use failure. With Poetry 2.4.1 the venv is created correctly by poetry install using the PATH Python placed there by setup-python — no extra wiring needed.

Python 3.14 added to the test matrix

crewai and litellm are already gated to python_version < "3.14" in pyproject.toml, so they are skipped cleanly. All other extras install and pass.

Added grpcio (>=1.80.0,<2.0.0) as an explicit optional dependency

grpcio was a transitive dep with a loose lower bound. Any resolver (Poetry, uv, pip) could legitimately pick a version below 1.80.0, which has no cp314 wheels. grpcio 1.80.0 is the first release with pre-built wheels for Python 3.14 on all platforms.

The constraint is added in both [project.optional-dependencies] (PEP 621 — read by uv/pip) and [tool.poetry.dependencies] (read by Poetry), under the otel and all extras. poetry.lock is regenerated via poetry lock and resolves to grpcio 1.81.1.

[fercor-cisco]

Note: The PR description is stale. It describes a poetry env remove --all && poetry env use step and id: setup-python that no longer exist — they were removed in commit 965e64e once Poetry was bumped to 2.4.1. The real fix is the version bump + assertion, not explicit venv recreation. This is the one thing I'd ask be corrected before merge.