build: restore maturin backend to bundle the Rust bridge in the wheel

[yuneng-berri]

Relevant issues

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Local build with maturin==1.9.4 (the pin the release pipeline uses) against Python 3.13, confirming the wheel carries both the native Rust module and the committed Admin UI bundle:

$ maturin build --out dist --interpreter .venv/bin/python
📦 Including files matching "litellm/proxy/_experimental/out/**"
📦 Built wheel for CPython 3.13 to dist/litellm-1.92.0-cp313-cp313-macosx_11_0_arm64.whl

$ unzip -l dist/*.whl | grep -E '_native|_experimental/out/index.html'
    22340  ...  litellm/proxy/_experimental/out/index.html
 16007296  ...  litellm/rust_bridge/_native.cpython-313-darwin.so

Type

🚄 Infrastructure

Changes

Re-applies the maturin build backend (reversing #31470, which had temporarily restored the pure-Python uv_build backend). maturin packages the Rust bridge (litellm.rust_bridge._native) into the wheel; litellm/rust_bridge/loader.py 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, so maturin wheels are PyPI-acceptable again. The maturin==1.9.4 pin here matches the pin the manylinux build path installs

The [tool.maturin] include = ["litellm/proxy/_experimental/out/**"] line is sdist coverage for the Admin UI bundle. maturin's include overrides .gitignore for the sdist but not for the wheel, so it is not wheel protection; litellm/proxy/_experimental/out/ stays committed and un-ignored, which is what puts the bundle into the wheel (maturin's python-source walk) and the sdist. No .gitignore changes and no bundle-cleanup are part of this PR

Coordination: this pairs with the release-pipeline change that builds the Admin UI from source and adds an offline gate on the built wheel/sdist for the bundle. That change should land first so the pipeline can build and verify a maturin UI wheel before this flips the backend to maturin

[greptile-apps]

Greptile Summary

This PR restores maturin as the PEP 517 build backend (replacing the temporary uv_build revert from #31470) so the Rust bridge (litellm.rust_bridge._native) is compiled and packaged into the wheel again, alongside the committed Admin UI bundle.

• Swaps requires = [\"uv_build==0.11.8\"] / build-backend = \"uv_build\" for maturin==1.9.4 and adds a [tool.maturin] table wiring up the python-bridge Cargo crate, pyo3 bindings, and include/exclude patterns.
• Removes the now-superseded [tool.uv.build-backend] section, porting its source-exclude globs into [tool.maturin].exclude (also adding the previously missing litellm/proxy/enterprise/** sub-glob).

Confidence Score: 4/5

Safe to merge once the companion release-pipeline change has landed; merging in isolation risks publishing a wheel without the native-module gate.

The pyproject.toml change itself is mechanically correct — the Cargo.toml exists, pyo3 bindings are appropriate, and the exclude globs are at least as strict as the ones they replace. The only real concern is the stated sequencing dependency: the release pipeline must be updated to build manylinux maturin wheels and validate their contents before this backend flip goes live. If that pipeline change is already merged, this PR is straightforwardly safe. If not, the first release after this merges could emit an unvalidated wheel.

pyproject.toml — verify the companion pipeline change is merged before this lands

Important Files Changed

Filename	Overview
pyproject.toml	Switches the build backend from uv_build==0.11.8 to maturin==1.9.4, adds [tool.maturin] config pointing at the Rust bridge crate, and removes the [tool.uv.build-backend] section; the referenced Cargo.toml exists and the loader.py graceful-fallback path is unaffected

_{Reviews (1): Last reviewed commit: "build: restore maturin backend to bundle..." | Re-trigger Greptile}

[greptile-apps]

Merge ordering dependency not enforced

The PR description explicitly states that the companion release-pipeline change (which builds the Admin UI from source and gates the wheel on containing the native module) must land before this PR. If this pyproject.toml flip merges first, the existing pipeline will attempt a maturin build but lack the validation logic, meaning a malformed or UI-less wheel could be published to PyPI before the gate is in place. Consider blocking this PR in the merge queue until the pipeline PR is confirmed merged, or adding a CI step here that fails if the pipeline does not already support maturin wheels.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mateo-berri]

The only real concern is the stated sequencing dependency: the release pipeline must be updated to build manylinux maturin wheels and validate their contents before this backend flip goes live. If that pipeline change is already merged, this PR is straightforwardly safe. If not, the first release after this merges could emit an unvalidated wheel.

Is this a valid concern?

I see the in-tandem project releaser pr and it seems ready

[mateo-berri]

LGTM; thanks!