Kenapa Michal Gorny Minta Proyek Python Berhenti Pakai uv-build sebagai Build Backend

Pengembang Gentoo Michał Górny meminta proyek Python berhenti memakai uv-build sebagai build backend, dan alasannya soal ukuran serta portabilitas, bukan soal kecepatan. Dalam tulisan yang dipublikasikan 12 Oktober 2026, ia menyebut wheel uv-build berukuran 1,2 sampai 1,5 MiB sementara backend murni Python seperti flit-core hanya 45 KiB, sehingga setiap pengguna Gentoo harus membangun ulang backend tersebut dari sumber. Permintaannya bukan menolak uv secara keseluruhan, melainkan memisahkan tool yang bagus dari satu komponen yang dianggap merugikan distribusi Linux.

TL;DR

• Michał Górny (Gentoo) meminta proyek Python menghindari uv-build sebagai build backend lewat tulisan 12 Oktober 2026.
• Wheel uv-build berukuran 1,2 sampai 1,5 MiB, sedangkan flit-core hanya 45 KiB, karena uv-build ditulis dalam Rust.
• uv-build rilis sangat sering, 12 rilis dalam 30 hari sebelum tulisan itu, sehingga pengguna source distribution terus membangun ulang.
• Masalah terbesarnya portabilitas: Rust belum didukung di semua platform, dan uv punya masalah alamat memori di sistem 32-bit.
• Keuntungan performa uv-build hanya sekitar 100 ms untuk aksi yang jarang dijalankan, jadi tidak sebanding dengan biaya yang ditanggung packager.

Apa itu uv-build dan kenapa dipakai?

uv-build adalah build backend resmi dari Astral, perusahaan di balik uv, yang tugasnya mengubah direktori source menjadi source distribution atau wheel sesuai standar PEP 517. Backend adalah komponen yang dipanggil saat seseorang menjalankan perintah build, dan sejak PEP 517 ditetapkan, frontend apa pun bisa dipasangkan dengan backend apa pun.

Alasan utama proyek memilih uv-build ada dua. Pertama, konsistensi: kalau seluruh alur proyek sudah memakai uv, memakai backend yang sama terasa lebih rapi. Kedua, performa, karena backend ini dikompilasi sehingga lebih cepat daripada backend Python murni. Górny menilai argumen konsistensi tidak berlaku, sebab inti PEP 517 memang memisahkan frontend dari backend, jadi flit-core atau hatchling bisa dipakai berdampingan dengan uv tanpa masalah. Argumen performa juga lemah karena backend hanya dijalankan sesekali, terutama oleh pengembang, kontributor, dan packager distribusi, bukan oleh pengguna akhir yang hampir selalu memasang wheel siap pakai.

Kenapa ukuran wheel jadi masalah besar?

Karena di distribusi berbasis source seperti Gentoo, ukuran wheel bukan sekadar soal unduhan, melainkan soal waktu kompilasi yang diulang setiap rilis. Górny menjelaskan bahwa uv-build yang ditulis dalam Rust membuat setiap pengguna Gentoo harus membangunnya dari sumber, dan frekuensi rilisnya memperburuk keadaan: ada 12 rilis dalam 30 hari sebelum tulisan itu dibuat. Bandingkan dengan backend Python murni yang hanya perlu disalin, bukan dikompilasi.

Ia memberi gambaran biaya yang tidak seimbang. Setiap 100 ms yang dihemat uv-build saat memasang satu rilis paket, pengguna Gentoo harus menukarnya dengan berjam-jam kompilasi versi uv-build baru yang terus muncul. Keuntungan di satu sisi dibayar jauh lebih mahal di sisi lain, dan pihak yang menanggungnya adalah packager serta pengguna source distribution, kelompok terbesar yang benar-benar menjalankan backend.

Aspek	uv-build	flit-core
Bahasa	Rust	Python murni
Ukuran wheel	1,2 sampai 1,5 MiB	Sekitar 45 KiB
Perlu kompilasi di Gentoo	Ya, tiap rilis	Tidak
Frekuensi rilis	12 rilis dalam 30 hari	Jarang
Keuntungan performa	Sekitar 100 ms	Tidak ada, tapi cukup

Seberapa serius masalah portabilitasnya?

Cukup serius untuk distribusi yang mendukung arsitektur langka. Python bisa dijalankan hampir di mana saja selama ada compiler C yang berfungsi, sedangkan dukungan platform Rust bertambah lambat dan tidak merata. Górny menyebut beberapa masalah konkret: crate rustix::fs beserta dependensinya melewatkan platform SPARC tanpa alasan yang jelas, dan pada sistem 32-bit executable hasil kompilasi bisa begitu besar sampai toolchain kehabisan ruang alamat. Ebuild uv di Gentoo bahkan sudah membawa dua trik khusus agar uv bisa dibangun di platform 32-bit.

Kalau sebuah platform sama sekali belum didukung, menambahkannya bukan pekerjaan sehari. Górny menyebut upaya menambah dan merawat platform baru sebagai pekerjaan penuh waktu yang penuh drama, terutama karena kode yang berubah cepat. Untuk distribusi yang menjaga banyak arsitektur sekaligus, beban ini menumpuk dengan cepat.

Bagaimana cara pindah dari uv-build ke backend lain?

Cukup ubah bagian build-system di pyproject.toml, karena PEP 517 memisahkan frontend dari backend. Kamu tidak perlu mengganti uv sebagai tool harian, hanya backend yang dipanggil saat build. Perubahan ini biasanya satu blok kecil dan tidak menyentuh kode aplikasi sama sekali.

[build-system]
requires = ["flit-core>=3.9"]
build-backend = "flit_core.buildapi"

Untuk paket dengan satu modul utama, flit-core paling ringkas karena konfigurasinya minimal. Kalau proyekmu butuh plugin build, memasukkan file data, atau hook khusus, hatchling lebih fleksibel dan tetap Python murni. Setelah mengganti backend, jalankan build sekali di lingkungan bersih untuk memastikan wheel yang dihasilkan tetap berisi berkas yang sama, lalu bandingkan daftar isinya dengan wheel versi sebelumnya.

Kalau kamu memelihara paket di distribusi Linux, perubahan ini juga menghapus satu dependensi kompilasi dari pohon build. Itu berarti ebuild atau paket distribusimu tidak lagi perlu menunggu uv-build dibangun ulang setiap kali versinya naik, dan platform yang didukung Rust terbatas tidak lagi menjadi penghalang.

Apa kata pihak Astral soal kritik ini?

Belum ada tanggapan resmi yang dipublikasikan, tetapi konteksnya penting. Górny sendiri menyebut uv dan tool Astral lain sebagai tool bagus dengan upstream yang responsif, jadi kritiknya tertuju pada satu komponen, bukan pada perusahaan atau ekosistemnya. Sikap itu meninggalkan ruang untuk perbaikan tanpa memancing perdebatan pribadi.

Yang bisa diprediksi adalah arah teknis uv-build. Selama backend ini ditulis dalam Rust, ukuran wheel dan kebutuhan kompilasi akan tetap ada, karena keduanya konsekuensi langsung dari bahasa yang dipakai. Kalau Astral ingin menjawab keberatan ini, opsinya adalah mengecilkan biner, memperluas dukungan platform, atau menyediakan backend Python murni sebagai alternatif. Sampai salah satunya terwujud, saran Górny akan terus relevan untuk packager distribusi.

Siapa yang paling terdampak keputusan ini?

Packager distribusi dan pengguna source distribution. Menurut Górny, pengguna source distribution adalah kelompok terbesar yang benar-benar menjalankan backend, dan justru mereka yang paling dirugikan karena harus membangun uv-build berulang kali. Pengguna yang memasang wheel siap pakai praktis tidak terpengaruh.

Dampaknya juga terasa di CI. Pipeline yang membangun paket dari source untuk banyak target arsitektur akan menambah satu langkah kompilasi berukuran besar di setiap target, dan langkah itu gagal di platform yang belum didukung Rust. Dalam skala organisasi, biaya kecil yang diulang ribuan kali berubah menjadi beban nyata, dan itulah inti keberatan yang disampaikan Górny.

Apakah uv-build tetap cocok untuk proyek tertentu?

Bisa, asalkan proyekmu tidak pernah dibangun dari source oleh pengguna platform langka. Kalau paketmu hanya dirilis sebagai wheel untuk platform populer, kebutuhan kompilasi uv-build tidak pernah terasa karena tidak ada yang menjalankan backend di mesin mereka. Kritik Górny menyasar kasus ketika source distribution harus dibangun, dan itu yang dialami distribusi seperti Gentoo.

Untuk proyek yang memang menargetkan banyak arsitektur, flit-core atau hatchling tetap pilihan yang lebih aman. Keduanya kecil, Python murni, dan tidak menambah dependensi kompilasi ke pohon build packager. Keputusan backend sebaiknya diambil dengan mempertimbangkan siapa yang membangun paketmu, bukan siapa yang memakainya.

Kalau kamu ragu, tanyakan langsung ke maintainer distribusi yang mengemas paketmu. Mereka biasanya tahu persis platform mana yang bermasalah, dan masukan mereka jauh lebih berguna daripada membandingkan benchmark build yang hanya terasa di mesin pengembang.

Apa dampaknya buat kamu sebagai pengguna Python biasa?

Untuk pengguna yang memasang paket dari wheel, dampaknya hampir nol. Kalau kamu menjalankan pip install atau uv add dan paketnya punya wheel siap pakai, backend tidak pernah dipanggil sama sekali. Backend baru aktif saat kamu memasang dari source distribution, entah karena platformmu tidak punya wheel atau karena paketnya memang dirilis sebagai source.

Dampaknya mulai terasa kalau kamu mengelola sistem sendiri, menjadi maintainer paket, atau menjalankan CI yang membangun dari source. Di situ, memilih uv-build menambah langkah kompilasi yang tidak perlu dan memperbesar peluang gagal di arsitektur yang kurang umum. Górny menekankan bahwa justru kelompok inilah yang paling terdampak, dan mereka bukan pengguna kasual yang bisa mengabaikan biaya kompilasi.

Backend apa yang sebaiknya dipakai?

Untuk paket Python murni, flit-core atau hatchling sudah lebih dari cukup. Keduanya Python murni, berukuran kecil, dan berjalan baik bersama uv maupun pip sebagai frontend. Kamu tetap bisa memakai uv untuk mengelola virtual environment, menjalankan perintah, dan memasang dependensi, sambil membiarkan build backend tetap ringan dan portabel.

uv-build baru masuk akal kalau proyekmu memang butuh fitur khusus yang hanya disediakan backend tersebut, atau kalau kamu tidak peduli dengan paket yang dibangun dari source di platform langka. Kalau ragu, tanyakan dulu ke packager distribusi yang menargetkan platformmu. Satu baris di pyproject.toml bisa menentukan apakah pengguna SPARC atau 32-bit bisa memasang paketmu atau tidak. Dokumentasi resmi uv untuk backend ini ada di halaman build backend uv, dan spesifikasi PEP 517 yang menjadi dasarnya ada di peps.python.org. Tulisan asli Górny bisa dibaca di blog Gentoo miliknya, dan metadata paket uv-build termasuk lisensi serta syarat versi Python tercatat di PyPI.

FAQ

Apakah uv sendiri juga disarankan untuk dihindari?

Tidak. Górny secara eksplisit memuji uv dan tool Astral lainnya sebagai tool bagus dengan upstream yang responsif. Yang ia tolak hanya uv-build sebagai build backend, karena biaya portabilitasnya jatuh ke packager distribusi.

Kalau proyek saya sudah pakai uv-build, apakah harus buru-buru pindah?

Kalau proyekmu murni Python dan dibangun dari source oleh pengguna lain, sebaiknya pertimbangkan pindah ke flit-core atau hatchling. Perpindahan backend biasanya cukup mengubah satu bagian di pyproject.toml, tanpa mengubah alur pengembangan.

Apakah backend yang berbeda mengubah cara kerja uv?

Tidak. PEP 517 dirancang supaya frontend dan backend bisa dipasangkan bebas. uv tetap bisa memasang, menjalankan, dan mengelola proyekmu meski backend-nya bukan uv-build, jadi tidak ada kehilangan fungsi.

Apakah wheel uv-build yang besar benar-benar memperlambat install?

Untuk pengguna yang memasang wheel siap pakai, tidak. Yang terbebani adalah mereka yang membangun dari source, karena mereka harus mengompilasi backend berukuran 1,2 sampai 1,5 MiB setiap kali versinya naik, dan versinya naik sangat sering.

Inti keberatan Górny bukan soal mana yang lebih cepat, melainkan soal siapa yang menanggung biaya. uv-build memindahkan beban kompilasi dan portabilitas dari pembuat tool ke packager distribusi, dan itu bertentangan dengan semangat PEP 517 yang justru ingin backend ringan dan bisa ditukar bebas. Kalau kamu memilih backend untuk proyek baru, putuskan berdasarkan siapa yang akan membangun paketmu dari source, bukan berdasarkan selisih 100 ms yang jarang terasa.

Rekomendasi Tools & Layanan

Mau langsung nyobain AI yang dibahas di artikel ini tanpa setup ribet? AI token plan Alibaba Cloud ngasih akses ke Qwen, DeepSeek, dan model lain lewat satu API — dan platform Qwen buat build agent sendiri. Free tier-nya cukup buat eksperimen pertama.