Gentoo 打包者呼籲：純 Python 專案別把 build backend 換成 uv-build
Michał Górny（Gentoo）· 2026-10-12
純 Python 專案把 pyproject.toml 的 build backend 從 flit-core 或 hatchling 換成 uv-build，換來的是「和 uv 同一家」的一致感，代價卻轉嫁給每一位要從原始碼打包的下游。Gentoo 開發者 Michał Górny 在 2026-10-12 發文，請專案作者不要這樣做。
他明說這不是批評 uv 或 Astral 的工具，問題出在「build backend」這個位置：它必須在每次建置時先被取得、先被編譯。
原本的問題
依照 PEP 517，專案在 [build-system] 以 requires 列出建置依賴，以 build-backend 指名負責建置的物件，前端（pip、uv 等）只呼叫 build_wheel、build_sdist 等 hook。也就是說，前端與後端本來就可以任意搭配，用 uv 管專案不代表一定要用 uv-build 當後端。
flit-core 與 hatchling 都是純 Python 後端。uv-build 則是 uv 的精簡版本，只保留建置後端，用 Rust 寫成，在 PyPI 上以預編譯 wheel 發行。對一般使用者來說，下載 wheel 即可；對必須從原始碼建置每個套件的發行版（Górny 以 Gentoo 為例），後端本身就得先經過一次 Rust 編譯。
三個具體成本
- 體積與建置時間：Górny 指出 uv-build 的 wheel 約 1.2 至 1.5 MiB，flit-core 約 45 KiB。PyPI 頁面顯示
0.13.0（2026-10-09 發布）的 wheel 為 1.2 MB 至 1.6 MB，sdist 為 443.0 kB。他也提到 uv-build 發版頻繁，每次都要重新編譯。 - 平台支援：Rust 的平台支援有限，依賴項或二進位大小可能讓 32 位元等平台建置失敗。
- 效能優勢很小：他估計比其他後端快約 100 ms，但下載與編譯後端的成本，對 sdist 使用者而言遠大於此。
實際的失敗案例
平台問題不是假設。Górny 在 2026-10-10 於 rustix 開了 issue #1700：在 SPARC64 上建置 uv 時，rustix v1.1.5 找不到 ioctl_ficlone，也解析不到 FS_IOC_FIEMAP 與一組 FIEMAP_EXTENT_* 常數，錯誤指向 crates/uv-fs/src/space.rs 與 crates/uv-fs/src/link.rs。他注意到這些符號在系統的 /usr/include/linux/fiemap.h 裡存在。截至我們抓取時，這個 issue 仍是 open，沒有留言或關聯 PR。
這個例子的重點在於：一個只想打包純 Python 函式庫的人，會因為上游選了 uv-build，而被迫處理 SPARC64 上的 Rust 依賴問題。
影響範圍與改法
受影響的是兩類人：發行版維護者（Gentoo 之類從原始碼建置的系統），以及在非主流架構或 32 位元平台上安裝你套件 sdist 的使用者。純 Python 專案若用 uv-build，對方的安裝流程就多了一個 Rust 工具鏈需求。
要檢查的是 pyproject.toml 裡 [build-system] 的 requires 與 build-backend 兩個欄位。換成 flit-core 或 hatchling 不需要改前端，使用者照常用 uv 即可（具體的後端名稱請依各專案文件填寫，原文未給設定範例）。
文中推薦的替代品是 flit-core 與 hatchling。Górny 的論點僅限純 Python 套件；他認為對這類套件，uv-build 的缺點大於好處，文章並未討論含編譯擴充的專案。
另外，uv-build 的 PyPI 頁面沒有列出任何使用限制，上述判斷全是下游打包者的觀點，Astral 方面是否回應，文章未提及。
原始來源：Gentoo 部落格原文、rustix issue #1700、uv-build on PyPI、PEP 517