Prepare DSPy for Python 3.15

[migurski]

Summary

This PR adds Python 3.15 support to DSPy. With it, pip install dspy and uv add dspy both work on 3.15 from wheels, with no Rust toolchain and no build flags, and LM calls run through the bundled lm15 engine. pydantic 2.14.0 (released 2026-10-08) supplies the cp315 pydantic-core wheels this depends on.

Changes

1. Raise requires-python from <3.15 to <3.16. DSPy made the same change from <3.14 to <3.15 at 3.1.0 for the 3.14 cycle.
2. Install litellm and gepa only below 3.15. Both declare requires-python <3.15. pip honours that, so without this change pip install dspy fails on 3.15: it rejects gepa==0.1.4, then falls back to litellm 1.83.7, whose pinned fastuuid and pydantic-core have no cp315 wheels and do not build under PyO3 0.26. uv ignores the cap but still has to build fastuuid from source, which needs Rust and PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1.
   • The lm15 engine serves LM calls without litellm. The litellm-only paths already raise DSPy's require() install hint.
   • dspy.GEPA becomes a stand-in that raises ImportError when gepa is absent, so import dspy still works.
3. Declare jsonschema. dspy/adapters/types/tool.py imports it, but it only arrived through litellm.
4. Add 3.15 to the test, extra_test, and build_package matrices as allowed failures (continue-on-error) while 3.15 is a release candidate. allow-prereleases: true lets the leg use the 3.15 rc interpreter. The dev extra keeps litellm and gepa on 3.15, so these legs still test the LiteLLM and GEPA paths. Those legs set PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 so fastuuid builds.
5. Widen two exact-3.14 conditions to 3.14 and later. The dev extra selects litellm[proxy] only below 3.14, and the LiteLLM proxy test fixture skips only on 3.14 exactly.
6. Update uv.lock. pydantic goes to 2.14.0 and pydantic-core to 2.50.0. The 3.15 resolve takes pyarrow 26.0.0 because pyarrow 25.0.1 has no cp315 wheel.

Verification

On CPython 3.15.0rc3 (linux aarch64), installing the built wheel into a fresh venv with no Rust on PATH and no pyo3 variable:

Installer	Install	Predict (default engine)	dspy.GEPA(...)	dspy.Embedder("openai/...")
pip 26.2.1	succeeds	works	ImportError: gepa is required	ImportError: install dspy[litellm]
uv	succeeds	works	ImportError: gepa is required	ImportError: install dspy[litellm]

On 3.12, pip still installs litellm and gepa, and dspy.GEPA constructs normally.

Test suites through uv sync with the dev extras:

Python	-m 'not extra and not deno'	-m 'extra or deno'
3.15.0rc3	2433 passed, 310 skipped, 2 xfailed	244 passed, 2 skipped
3.12	2443 passed, 300 skipped, 2 xfailed	244 passed, 2 skipped

The "Dependencies (latest)" check fails on main as well (test_lm_wraps_litellm_errors_with_metadata), so this PR does not cause it.

Limits on 3.15 outside DSPy

• LiteLLM features (engine="litellm", Embedder with a model string, the LiteLLM logging helpers, and providers or client settings lm15 does not route) need litellm. pip cannot install litellm on 3.15 because of its requires-python <3.15. uv can, but needs Rust and PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 until fastuuid ships cp315 wheels (Publish CPython 3.15(t) wheels fastuuid/fastuuid#71), and litellm 1.102.0 and later import sre_constants, which Python 3.15 removed. Pin litellm<1.102 on 3.15 for now.
• GEPA needs gepa, which declares requires-python <3.15. uv can install it on 3.15; pip cannot.

These lift once litellm and gepa support 3.15. DSPy then needs to drop the python_version < '3.15' markers and bump the exact gepa pin.

---

Prepared with the help of a coding agent (Claude Code); reviewed before submitting.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] No outstanding findings block merging.

Summary

The PR expands DSPy’s supported Python range to 3.15, makes incompatible dependencies conditional, updates the lockfile, and adds provisional 3.15 CI coverage. No outstanding findings remain.

_{Reviews (5) · Last reviewed commit: "fix: keep the GEPA stand-in a Teleprompt..." · Reviewed by Greptile}

[migurski]

Thanks for the review — addressed in the latest push:

• uv.lock (25c9542): regenerated for the raised requires-python, so it no longer lags pyproject.toml and a frozen sync accepts the <3.16 range.
• 3.15 fail-fast / red main (6af725b): the 3.15 matrix value is now continue-on-error in test, extra_test and build_package. It still runs and reports, but no longer fails the workflow or, under the default fail-fast, cancels the 3.10–3.14 legs.
• On “the pydantic-specific explanation is not supported by this run”: with the abi3 forward-compat flag removed, fastuuid is the first build wall — which is what the run shows. pydantic-core is the deeper one: with the flag it fails to compile because it subclasses the native PyTzInfo type, which pyo3's abi3 forbids, so no build flag rescues it. The clean fix is a prebuilt cp315 wheel, and it is imminent — pydantic 2.14.0 pins a cp315-capable pydantic-core, already proven by the published 2.14.0b2 pre-release (pins pydantic-core 2.49.0, which ships cp315 wheels). The workflow note now states this.

[migurski]

Pydantic 2.14.0 is out, I am updating this PR to reflect it.