fix(build): restore pure-Python uv_build backend to unblock PyPI publish - #31470
Conversation
#31267 switched the build backend to maturin to bundle the Rust OCR bridge into the litellm wheel. On the release runner, maturin builds with `--compatibility off` and emits a `cp312-cp312-linux_x86_64` wheel. PyPI only accepts `manylinux*` Linux wheels, so the upload is rejected with `400 Bad Request - unsupported platform tag 'linux_x86_64'`, which blocked the 1.91.0.dev2 publish. Revert `[build-system]` to the pure-Python `uv_build` backend and restore `[tool.uv.build-backend]` so the release once again produces a universal `litellm-<ver>-py3-none-any.whl` that installs on every OS / arch / Python. The Rust bridge stays optional: `litellm/rust_bridge/loader.py` already falls back gracefully when `_native` is absent (`try/except ImportError`), so runtime behavior is unchanged - the native module is simply not bundled. Rust acceleration can ship as a separate platform-specific package later.
Greptile SummaryThis PR reverts the
Confidence Score: 5/5Single-file build config change that restores the prior pure-Python wheel; no runtime logic is modified and the author has verified the wheel tag locally. The change is a targeted revert of one build-system stanza, the proof-of-fix ( No files require special attention.
|
| Filename | Overview |
|---|---|
| pyproject.toml | Reverts build backend from maturin to uv_build, restoring pure-Python wheel generation; source-exclude list mirrors the old maturin exclude list (minus the redundant litellm/proxy/enterprise/** glob, which is harmless as uv_build excludes whole directory trees by default) |
Reviews (1): Last reviewed commit: "fix(build): restore pure-Python uv_build..." | Re-trigger Greptile
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Re-apply the maturin build backend (reverting BerriAI#31470, which had temporarily restored the pure-Python uv_build backend). maturin packages the Rust bridge (litellm.rust_bridge._native) into the wheel; the loader already falls back gracefully when the native module is absent, so pure-Python installs are unaffected. The earlier revert was needed because the release pipeline emitted a bare cp312 linux_x86_64 wheel that PyPI rejects. That is resolved on the pipeline side: it now branches on the build backend and, for maturin, builds proper manylinux_2_28 wheels (x86_64 + aarch64) and validates each wheel carries the native module. The [tool.maturin] include for litellm/proxy/_experimental/out/** is sdist coverage for the Admin UI bundle. maturin's include overrides .gitignore for the sdist but not the wheel; the committed bundle stays tracked and un-ignored, so it flows into both the wheel (maturin's source walk) and the sdist as-is. Coordinates with the release pipeline change that builds the Admin UI from source and gates the built wheel/sdist on the bundle being present; that should land first so the pipeline can build and verify a maturin UI wheel.
3 participants
Relevant issues
PyPI publish failure on the
1.91.0.dev2release: the litellm wheel was rejected by PyPI with400 Bad Request - Binary wheel 'litellm-1.91.0.dev2-cp312-cp312-linux_x86_64.whl' has an unsupported platform tag 'linux_x86_64'.Linear ticket
Pre-Submission checklist
make test-unitType
🐛 Bug Fix
🚄 Infrastructure
Changes
Problem. #31267 switched the build backend from
uv_buildtomaturinto bundle the Rust OCR bridge into the litellm wheel, making litellm a compiled package. When the release builds withpython -m buildon a stock runner (no manylinux container), maturin defaults to--compatibility offand emits acp312-cp312-linux_x86_64wheel. PyPI only acceptsmanylinux*Linux wheels, so the upload fails and the publish is blocked.Fix. Revert
[build-system]to the pure-Pythonuv_buildbackend and restore[tool.uv.build-backend]. The release again produces a universallitellm-<ver>-py3-none-any.whlthat installs on every OS / arch / Python version.The Rust bridge remains optional —
litellm/rust_bridge/loader.pyalready degrades gracefully when the native module is missing (try/except ImportError), so runtime behavior is unchanged; the compiled_nativemodule is simply not bundled in the wheel. Bundling Rust into the published wheel requires a full multi-platform wheel matrix (manylinux + macOS + Windows × x86_64 + aarch64 × supported Pythons) in the release pipeline, which can be pursued separately if/when we want the native path shipped on PyPI.Proof of Fix
Built locally with
uv build --wheel:litellm-1.91.0.dev2-cp312-cp312-linux_x86_64.whl→ rejected by PyPI (unsupported platform tag)litellm-1.91.0-py3-none-any.whl→Root-Is-Purelib: true,Tag: py3-none-anyThe pure-Python
litellm/rust_bridge/package (__init__.py,loader.py) is still included in the wheel; no.so/_nativeextension is present, confirming the graceful pure-Python path.Out of scope (follow-ups)
litellm-rust/source is still included in the sdist (harmless); can be excluded later if desired.