You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 9f3fcdc
Browse filesBrowse the repository at this point in the historyBrowse files
* build: raise requires-python cap to <3.16 for Python 3.15
Python 3.15 is being released, but every published dspy declares
requires-python >=3.10,<3.15, so pip/uv refuse to install dspy on
3.15 at resolution time. This raises the upper bound to <3.16 so the
package can be installed and exercised on 3.15.
Metadata-only. It does not itself assert full 3.15 support; it opens
the door to validating and releasing it. Happy to help test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: add Python 3.15 to the test and build matrices
Adds 3.15 to the test, extra_test and build_package matrices so the
suite and the wheel build are exercised on 3.15. allow-prereleases lets
the 3.15 leg acquire an interpreter before GA; it is a no-op for the
versions that already have stable builds and once 3.15 is released.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: allow pyo3 forward-compat so the 3.15 leg builds sdist deps
The 3.15 matrix leg fails at `uv sync`: fastuuid (and other pyo3
extensions) have no cp315 wheel yet, so uv builds them from sdist and
pyo3 refuses to build against a Python newer than its max supported.
PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 is pyo3's documented escape hatch:
build against the stable ABI, run forward-compatibly on 3.15. It is a
no-op on versions with a prebuilt wheel. Drop once deps ship cp315.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: keep 3.15 red without a hack; document the upstream unlock
Remove the pyo3 abi3 forward-compat env: it cannot make the 3.15 leg
green anyway, because pydantic-core subclasses the native PyTzInfo type
that abi3 forbids. Instead leave the 3.15 leg failing and document why
and what fixes it: the leg goes green with no change here once pydantic
ships a release bundling pydantic-core >= 2.48 (first with cp315 wheels).
Today the newest pydantic (2.13.5) pins pydantic-core 2.46.5, which has
no cp315 wheel, so uv builds it from source and pyo3 cannot compile it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* build: regenerate uv.lock for the raised requires-python
pyproject raised requires-python to <3.16; regenerate the lock so it
matches (its requires-python and resolution-markers now cover 3.15).
No dependency versions change. Fixes the pyproject/lock mismatch that a
frozen install would reject.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: make the 3.15 leg an allowed failure and cite the pydantic unlock
The 3.15 legs fail until their native deps ship cp315 wheels, and the
matrix defaults to fail-fast, so a red 3.15 leg cancels the 3.10-3.14
legs and reddens main. Add continue-on-error for the 3.15 matrix value
in test, extra_test and build_package so 3.15 still runs and reports but
neither fails the workflow nor cancels the other legs.
Update the note with the concrete unlock: pydantic 2.14.0 pins a
cp315-capable pydantic-core -- already proven by the published 2.14.0b2
pre-release (pydantic-core 2.49.0, which ships cp315 wheels) -- so once
2.14.0 releases the leg installs from wheels and greens with no change
here. Also name fastuuid as the first build wall.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* build: unblock the 3.15 leg now that pydantic 2.14.0 is released
pydantic 2.14.0 pins pydantic-core 2.50.0, which ships cp315 wheels.
Bump both in uv.lock, and bump pyarrow to 26.0.0 for the 3.15 resolve
because 25.0.1 has no cp315 wheel.
fastuuid (a litellm dependency) still has no cp315 wheel, and its pyo3
0.26 rejects a Python past 3.14. Set PYO3_USE_ABI3_FORWARD_COMPATIBILITY
on the 3.15 legs of test, extra_test and build_package so it builds
against the stable ABI. pydantic-core no longer needs this path because
it now installs from a wheel.
The dev extra and the LiteLLM proxy test skip matched Python 3.14
exactly, so 3.15 got neither litellm[proxy] nor the skip and 10 proxy
tests errored. Widen both to 3.14 and later.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* build: install on Python 3.15 without litellm or gepa
litellm (since 1.93.0) and gepa 0.1.4 declare requires-python <3.15.
pip honours that, so `pip install dspy` failed on 3.15: it rejected
gepa, then fell back to litellm 1.83.7, whose pinned fastuuid and
pydantic-core have no cp315 wheels and cannot build under PyO3 0.26.
uv ignores the cap but still had to build fastuuid from source, which
needs Rust plus PYO3_USE_ABI3_FORWARD_COMPATIBILITY.
Mark litellm and gepa `python_version < '3.15'` in the core
dependencies. The bundled lm15 engine serves LM calls without litellm,
and the existing `require()` helper reports an install hint for the
litellm-only paths. Declare jsonschema, which dspy/adapters/types/tool.py
imports but which only arrived through litellm. Replace dspy.GEPA with
a stand-in that raises ImportError when gepa is absent, so `import dspy`
still works. Keep gepa in the dev extra so the 3.15 CI legs still test
GEPA.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* fix: keep the GEPA stand-in a Teleprompter
Code that wraps dspy.GEPA reads GEPA.__init__ and GEPA.compile at
import time; cmpnd's auto_instrument does. The bare stand-in class had
no compile, so on Python 3.15 without gepa that code raised
AttributeError before the user ever constructed a GEPA. Subclass
Teleprompter so the stand-in has the same interface, and still raise
ImportError on construction.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments