uv 0.13.7: Cara Audit Dependency Python dengan OSV

uv 0.13.7 dirilis 3 November 2026 dan membawa dua perubahan yang berguna untuk alur kerja audit dependency Python: uv audit kini melaporkan catatan OSV yang saling beralias sebagai satu kerentanan, bukan beberapa temuan terpisah, dan uv workspace metadata menerima opsi --output-version untuk meminta versi skema tertentu. Keduanya masuk kategori preview, jadi baca dulu dokumentasinya sebelum menjadikannya gerbang wajib di CI.

TL;DR

• uv 0.13.7 terbit 3 November 2026, perubahannya didominasi perbaikan, bukan fitur baru.
• uv audit sekarang menggabungkan catatan OSV yang beralias menjadi satu laporan.
• uv workspace metadata --output-version memungkinkan permintaan versi skema eksplisit.
• uv init dan uv add tidak lagi memperlakukan path anggota workspace sebagai pola glob.
• uv add mempertahankan komentar di sekitar grup dependency inline saat memperbarui.

Apa gunanya uv audit dan apa yang berubah di 0.13.7?

uv audit memeriksa dependency proyek terhadap basis data kerentanan OSV. Masalah yang lazim muncul: satu kerentanan sering punya beberapa catatan, misalnya satu catatan untuk paket Python dan satu catatan untuk paket sumbernya di ekosistem lain. Sebelum rilis ini, catatan yang saling beralias bisa tampil sebagai beberapa temuan terpisah, sehingga jumlah kerentanan yang dilaporkan lebih besar dari masalah yang sebenarnya harus diselesaikan.

Setelah 0.13.7, catatan yang beralias dilaporkan sebagai satu kerentanan. Efek praktisnya bukan sekadar laporan yang lebih rapi: jumlah temuan menjadi angka yang bisa dipakai sebagai ambang, misalnya menggagalkan CI kalau ada lebih dari nol kerentanan tingkat tinggi. Selama satu masalah bisa muncul tiga kali, ambang seperti itu sulit dipertahankan.

Perlu dicatat, fitur ini berada di daftar preview pada catatan rilis. Perilakunya bisa berubah, dan itu alasan untuk tidak menjadikannya satu-satunya penjaga keamanan dependency. Pakai bersama tinjauan manual dan pembaruan berkala.

Bagaimana langkah menjalankan audit dependency dengan uv?

Alurnya singkat, dan yang menentukan kualitas hasil justru langkah persiapan, bukan perintah auditnya.

1. Pastikan lockfile ada dan sinkron dengan pyproject.toml. Audit yang dijalankan pada lockfile basi akan melaporkan kerentanan paket yang sudah tidak kamu pakai, atau melewatkan yang baru masuk.
2. Naikkan uv ke 0.13.7 lebih dulu. Tanpa itu, penggabungan catatan beralias tidak berlaku, dan kamu akan menghitung masalah yang sama lebih dari sekali.
3. Jalankan audit pada lingkungan yang sama dengan yang dipakai CI, bukan pada lingkungan pengembang yang punya paket tambahan.
4. Simpan keluarannya sebagai artefak. Perbandingan antar minggu jauh lebih berguna daripada satu potret pada hari audit dilakukan.
5. Perbaiki dari yang paling dekat ke akar: paket langsung lebih dulu, lalu paket transitif lewat pembaruan induknya.

Langkah kelima sering dibalik. Memperbarui paket transitif secara paksa sering menyelesaikan satu temuan tetapi memecah kontrak versi paket induk. Memperbarui induknya lebih aman, meskipun kadang menunggu rilis dari pihak lain.

Apa yang berubah pada workspace dan grup dependency?

Beberapa perbaikan di rilis ini menyentuh perilaku perintah yang dipakai setiap hari, dan sebagian di antaranya mengubah hasil pada kasus tepi yang dulu tidak terasa.

Perintah	Perubahan	Efek pada proyek
uv init, uv add	Path anggota workspace diperlakukan sebagai literal, bukan pola glob	Nama direktori dengan karakter khusus tidak lagi salah diartikan
uv init	Nama modul dibuat valid untuk proyek paket yang diawali angka	Tidak perlu mengganti nama proyek hanya karena aturan penamaan modul
uv add	Komentar di sekitar grup dependency inline dipertahankan	Catatan alasan pemasangan tidak hilang saat menambah paket
uv remove	Berjalan dengan tabel tool.uv.sources inline yang kosong	Tidak gagal pada proyek yang pernah menghapus semua source
uvx	Bisa menjalankan tool pada build CPython dengan penanda lokal	Build CPython non-standar tidak lagi ditolak

Dua perbaikan pertama terlihat kecil, tetapi keduanya menyangkut hal yang sama: perlakuan terhadap teks yang diketik pengguna. Path yang diperlakukan sebagai pola glob bisa cocok dengan direktori lain tanpa niat, dan nama modul yang dihasilkan otomatis bisa tidak valid. Keduanya jenis bug yang sulit dilacak karena muncul sebagai perilaku aneh, bukan error jelas.

Kapan opsi --output-version dipakai?

Saat kamu punya alat lain yang membaca keluaran uv workspace metadata dan alat itu belum siap menerima versi skema terbaru. Dengan opsi ini, kamu bisa meminta versi skema tertentu dan menjaga integrasi tetap jalan tanpa menahan pembaruan uv.

Ini pola yang sehat untuk pipeline: alat pembaca dan alat penghasil tidak harus naik serentak. Yang penting, versi skema yang diminta dicatat di skrip, bukan dibiarkan mengikuti bawaan. Kalau tidak dicatat, pembaruan uv berikutnya bisa mengubah bentuk keluaran tanpa ada yang menyadarinya sampai pipeline gagal.

Untuk pemakaian satu kali di terminal, opsi ini jarang dibutuhkan. Nilainya muncul saat keluaran itu dikonsumsi mesin, misalnya skrip rilis atau generator dokumentasi.

Bagaimana cara upgrade yang aman?

Pasang lewat jalur yang sama dengan cara uv pertama kali dipasang. Kalau kamu memakai skrip installer resmi, jalankan ulang skrip itu dan biarkan ia mengganti biner. Kalau memakai pengelola paket sistem, tunggu paketnya ikut naik, atau pasang lewat installer resmi di direktori pengguna agar tidak bertabrakan dengan paket sistem.

Setelah naik, jalankan tiga pemeriksaan: versi uv, satu siklus uv sync pada proyek contoh, dan satu kali audit. Tiga pemeriksaan itu menutup jalur yang paling banyak berubah tanpa perlu menjalankan seluruh suite test proyek.

Satu hal yang mudah terlewat: pembaruan uv tidak mengubah isi lockfile secara otomatis. Jadi kalau lockfile dibuat versi lama, hasil uv sync tetap sama seperti sebelumnya. Perubahan baru terasa setelah lockfile dibuat ulang, dan itu sebaiknya dilakukan di branch terpisah supaya diff-nya bisa ditinjau.

Kesalahan apa yang sering terjadi saat memakai uv di CI?

Tiga pola berulang. Pertama, menjalankan audit pada lingkungan tanpa lockfile yang sinkron, sehingga hasilnya tidak mencerminkan apa yang benar-benar dipasang. Kedua, memakai uv versi berbeda antara mesin pengembang dan CI, sehingga perilaku perintah sama tetapi hasilnya berbeda pada kasus tepi. Ketiga, menganggap perbaikan performa sebagai jaminan tanpa mengukur waktu instalasi di pipeline sendiri.

Pola keempat lebih halus: memperlakukan keluaran audit sebagai daftar tugas yang harus habis. Dalam praktik, sebagian temuan berasal dari dependency transitif yang tidak bisa kamu perbarui sendiri. Untuk kasus itu, tindakan yang benar adalah mencatat pengecualian beserta alasannya, bukan memaksa versi yang belum didukung.

Rilis 0.13.7 tidak mengubah aturan main itu. Yang berubah adalah kualitas sinyal: laporan lebih ringkas, perilaku perintah lebih dapat diprediksi, dan beberapa bug yang dulu menggigit saat memakai workspace sudah diperbaiki.

Bagaimana memisahkan temuan audit yang bisa diperbaiki?

Bagi temuan menjadi tiga keranjang, dan putuskan tindakannya sebelum menyentuh lockfile. Keranjang pertama: paket yang kamu deklarasikan langsung. Ini yang paling mudah diperbaiki karena kamu memegang kendali versinya. Keranjang kedua: paket transitif yang punya induk tunggal. Perbaikannya lewat pembaruan induk. Keranjang ketiga: paket transitif yang dipakai banyak induk dengan batas versi saling bertentangan.

Keranjang ketiga yang paling sering menghabiskan waktu. Sebelum memaksa versi, periksa dulu apakah kerentanannya benar-benar bisa dijangkau dari kode yang kamu jalankan. Kalau jalur yang rentan tidak pernah dieksekusi, mencatat pengecualian dengan alasan yang jelas lebih jujur daripada memaksa kombinasi versi yang tidak diuji.

Dokumentasikan hasil pemisahan ini di berkas terpisah, bukan hanya di kepala. Audit berikutnya akan lebih cepat karena keputusan sebelumnya sudah tercatat, dan anggota tim baru tidak perlu mengulang analisis yang sama.

Apa dampak perbaikan handle di Windows?

Rilis ini memperbaiki trampolin di Windows agar tidak menutup handle yang bukan warisannya. Trampolin adalah lapisan perantara yang dipakai untuk menjalankan skrip Python dari paket yang dipasang sebagai executable. Kalau lapisan itu menutup handle milik proses lain, gejala yang muncul adalah kegagalan acak pada proses yang sebenarnya tidak berhubungan.

Bagi pengguna Linux dan macOS, perbaikan ini tidak mengubah apa pun. Bagi tim yang memakai Windows di sebagian mesin pengembang dan Linux di CI, perbaikan ini menghilangkan salah satu sumber perbedaan perilaku antar platform, jenis masalah yang paling melelahkan karena tidak bisa direproduksi di mesin yang dipakai untuk memperbaikinya.

Bagaimana merawat lockfile agar audit tetap relevan?

Perlakukan lockfile sebagai artefak yang punya jadwal. Perbarui secara berkala, tinjau diff-nya, lalu jalankan audit pada hasil yang baru. Lockfile yang dibiarkan berbulan-bulan membuat audit kehilangan gunanya, karena laporan yang keluar hanya menggambarkan dunia saat terakhir kali diperbarui.

Praktik yang bekerja: satu jadwal pembaruan rutin, satu jalur darurat untuk kerentanan kritis, dan satu aturan bahwa perubahan lockfile selalu melewati tinjauan. Tanpa aturan ketiga, pembaruan rutin akan bercampur dengan perubahan lain dan sulit dinilai apakah aman.

Rilis 0.13.7 juga memperbaiki contoh dokumentasi untuk kunci cache inline. Kalau kamu memakai konfigurasi cache di CI, periksa ulang contohnya setelah naik, karena contoh yang salah menghasilkan cache yang tidak pernah kena, dan itu terlihat sebagai build lambat tanpa pesan error.

Apakah uv cocok untuk proyek kecil?

Cocok, justru pada proyek kecil manfaatnya paling terasa karena tidak ada tim platform yang menyiapkan alat. Satu alat untuk resolusi, sinkronisasi, dan eksekusi tool menghilangkan beberapa lapisan yang biasanya harus dirawat sendiri. Untuk proyek dengan satu atau dua dependency, hasilnya sederhana: resolusi cepat, lingkungan konsisten, dan lockfile yang bisa dibaca.

Yang perlu dijaga hanya satu: jangan menambah aturan CI yang rumit sebelum kebutuhan itu muncul. Audit dependency mingguan dan pembaruan lockfile bulanan sudah cukup untuk sebagian besar proyek kecil, dan itu jauh lebih baik daripada proses berat yang akhirnya dilewati.

FAQ

Apakah uv audit sudah stabil untuk dijadikan gerbang CI?

Perubahannya masih ditandai preview, jadi perilakunya bisa bergeser antar rilis. Boleh dipakai sebagai peringatan di CI, tetapi jangan jadikan satu-satunya penentu sampai statusnya stabil.

Apakah 0.13.7 mengubah format lockfile?

Tidak ada perubahan format yang diumumkan di rilis ini. Yang berubah adalah perlakuan perintah terhadap path dan grup dependency, bukan struktur berkas lock.

Perlukah membuat ulang lockfile setelah upgrade?

Belum tentu. Buat ulang hanya kalau kamu memang ingin mengambil versi dependency terbaru. Untuk keperluan upgrade alat, uv sync pada lockfile yang ada sudah cukup dan lebih aman.

Bagaimana kalau proyek memakai build CPython khusus?

Rilis ini memperbaiki uvx agar bisa menjalankan tool pada build CPython yang versinya mengandung penanda lokal. Kalau sebelumnya kamu memakai build seperti itu dan gagal, coba lagi setelah naik ke 0.13.7.

Sumber utama tulisan ini adalah catatan rilis uv 0.13.7, dokumentasi resmi uv, dan basis data kerentanan OSV.