fix: cap requires-python <3.14 so uv can't pick a Python that fails to build litellm/pyo3

[shehabyasser-scale]

Bug

The v0.5 scale-vero package (vero/pyproject.toml on pr2-add-vero) declares requires-python = ">=3.11", which is too permissive. uv run picks the newest installed interpreter (e.g. Python 3.14). The transitive dependency litellm==1.92.0 (pulled via scale-vero[optimize] -> openai-agents[litellm]>=0.18.3,<0.19) has a Rust/PyO3 core that fails to build on Python 3.14.

Exact PyO3 error

error: the configured Python interpreter version (3.14) is newer than PyO3's maximum supported version (3.13)

Repro

On a machine whose default uv-managed Python is 3.14:

cd vero
uv run vero harbor run ...

uv resolves to Python 3.14 (satisfies >=3.11), then the litellm build fails with the PyO3 error above. Capping to <3.14 forces uv to select 3.11-3.13.

Fix

Cap the upper bound so uv cannot select an interpreter that breaks the litellm/PyO3 build:

-requires-python = ">=3.11"
+requires-python = ">=3.11,<3.14"

The repo has no .github/workflows CI matrix to reconcile against; the cap simply matches PyO3's max supported version (3.13). Change is limited to vero/pyproject.toml; nothing else is touched.

Why pr2-add-vero and not main

This supersedes #47 (which targeted main). The v0.5 package that ships the [optimize] extra as it exists today lives on pr2-add-vero (PR #45), and the sibling fix #48 (agent env) is also based on pr2-add-vero. Basing the fix here lets it flow to main through the stack (pr1 -> main, pr2 -> pr1, pr3 -> pr2).

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

Greptile Summary

This PR caps the Python version upper bound in vero/pyproject.toml from >=3.11 to >=3.11,<3.14, preventing uv from selecting Python 3.14 on machines where it is installed. The root cause is that openai-agents[litellm] pulls in a litellm build whose PyO3 Rust core only supports up to Python 3.13.

• Single-line change to requires-python in vero/pyproject.toml; no other files are touched.
• The cap correctly matches PyO3's documented maximum supported version (3.13) and is consistent with the existing [tool.ruff] target-version = "py311" setting.

Confidence Score: 5/5

Safe to merge — the change is a minimal version constraint tightening with a well-understood root cause and no other files affected.

The single-line cap to <3.14 directly matches PyO3's maximum supported Python version and is consistent with the existing ruff target-version = "py311". There is no risk of breaking existing 3.11–3.13 users, and the constraint will naturally be relaxed once a future litellm/PyO3 release adds 3.14 support.

No files require special attention.

Important Files Changed

Filename	Overview
vero/pyproject.toml	Caps requires-python to <3.14 to prevent uv from selecting Python 3.14, which breaks the litellm/PyO3 build; change is correct and minimal.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["uv run vero ..."] --> B{"Python version\nresolution"}
    B -- "Before fix\n(>=3.11)" --> C["Picks Python 3.14\n(newest available)"]
    B -- "After fix\n(>=3.11,<3.14)" --> D["Picks Python 3.11–3.13"]
    C --> E["openai-agents litellm extra\n→ litellm 1.92.0\n→ PyO3 build"]
    D --> F["openai-agents litellm extra\n→ litellm 1.92.0\n→ PyO3 build"]
    E --> G["❌ Build fails\nPyO3 max supported: 3.13"]
    F --> H["✅ Build succeeds"]

Loading

_{Reviews (1): Last reviewed commit: "fix: cap requires-python <3.14 so uv can..." | Re-trigger Greptile}

[varunursekar]

Landed on pr2-add-vero via cherry-pick as e4fe668 (your authorship preserved). Closing since GitHub won't auto-detect the cherry-picked SHA.

We hit this exact PyO3-on-3.14 build failure ourselves while running the benchmarks, so this is a real fix — thanks. The cap is now on the SSoT pr2 branch and pr3 is rebased on top; full suite green. We're keeping the manual --python 3.12 pins in our run/test commands for now but expect to drop them since uv can no longer pick 3.14.