Mengapa uv bisa menjadi secepat ini

• Manajer paket Python uv menunjukkan kecepatan instalasi lebih dari 10 kali lebih cepat dibanding pip, dan ini bukan semata karena ditulis dengan Rust, melainkan berasal dari pilihan desain
• Kunci utama yang memungkinkan kecepatan ini adalah standar metadata statis (PEP 518, 517, 621, 658), yang memungkinkan dependensi diketahui tanpa mengeksekusi kode
• uv dengan berani menghapus fitur legacy yang masih dipertahankan pip (.egg, pip.conf, instalasi Python sistem, dll.) sehingga jalur kode yang tidak perlu hilang
• Kontribusi Rust ada pada deserialisasi zero-copy, konkurensi tanpa lock, struktur biner tunggal, dan sejenisnya, tetapi itu hanya mencakup sebagian dari total peningkatan performa
• Secara keseluruhan, kasus uv menunjukkan bahwa metadata yang terstandarisasi dan penghapusan kompatibilitas yang tidak perlu adalah kunci inovasi performa

---

Standar yang memungkinkan kecepatan uv

• Lambatnya pip bukan masalah implementasi, melainkan akibat struktur lama berbasis setup.py, yang mengharuskan eksekusi kode untuk mengetahui dependensi
  • Menjalankan setup.py memerlukan instalasi dependensi build lebih dulu, yang memicu "masalah ayam dan telur"
  • Selama proses instalasi, terjadi eksekusi kode arbitrer dan kegagalan berulang, yang menurunkan kecepatan instalasi
• PEP 518 (2016) memperkenalkan pyproject.toml, sehingga dependensi build bisa dideklarasikan tanpa menjalankan kode
• PEP 517 (2017) memisahkan frontend dan backend build, sehingga pip tidak lagi perlu memahami bagian internal setuptools
• PEP 621 (2020) menstandarkan tabel [project], sehingga dependensi bisa diketahui hanya dengan parsing TOML
• PEP 658 (2022) memasukkan metadata paket langsung ke Simple Repository API, sehingga informasi dependensi bisa diambil tanpa mengunduh wheel
• PyPI menerapkan PEP 658 pada Mei 2023, dan uv dirilis pada Februari 2024, muncul sebagai alat pertama yang sepenuhnya memanfaatkan infrastruktur standar baru
• Seperti Cargo di Rust atau npm, ekosistem Python kini juga beralih ke packaging berbasis metadata statis

Fitur yang dihapus uv

• Kecepatan uv berasal dari penghapusan fitur yang tidak perlu
  • Tidak mendukung .egg: pip masih menanganinya, tetapi uv sepenuhnya mengecualikannya
  • Mengabaikan pip.conf: file konfigurasi, variabel lingkungan, dan logika pewarisan semuanya dilewati
  • Kompilasi bytecode dinonaktifkan: tidak mengubah .py menjadi .pyc, sehingga waktu instalasi lebih singkat
  • Virtual environment diwajibkan: tidak menginstal langsung ke Python sistem, sehingga pemeriksaan izin dan kode keamanan bisa dihapus
  • Kepatuhan spesifikasi yang ketat: paket yang salah langsung ditolak, sehingga logika penanganan pengecualian berkurang
  • Mengabaikan batas atas requires-python: batas defensif seperti python<4.0 diabaikan, sehingga resolusi dependensi (backtracking) berkurang
  • Indeks pertama diprioritaskan: jika paket ditemukan di indeks pertama dari beberapa indeks, proses langsung berhenti, sehingga mencegah serangan dependency confusion sekaligus mengurangi permintaan jaringan
• Semua ini adalah contoh bagaimana uv menghapus jalur kode yang masih harus dijalankan oleh pip

Optimasi yang mungkin tanpa Rust

• Sebagian besar kecepatan uv berasal dari optimasi desain yang tidak bergantung pada bahasa
  • Menggunakan permintaan HTTP Range untuk hanya mengunduh sebagian direktori pusat file wheel, sehingga tidak perlu mengunduh seluruh file
  • Unduhan paralel untuk mengambil beberapa paket sekaligus
  • Menggunakan cache global dan hardlink sehingga paket yang sama bisa dipasang di banyak virtual environment tanpa tambahan penggunaan ruang disk
  • Resolusi yang tidak bergantung pada Python: parsing TOML dan metadata wheel secara langsung, lalu hanya menjalankan Python jika yang tersedia hanya setup.py
  • Menggunakan algoritme resolusi dependensi PubGrub, yang lebih cepat daripada pendekatan backtracking milik pip dan memberi penjelasan error yang lebih jelas

Bagian yang benar-benar dibantu Rust

• Rust berperan penting pada optimasi level rendah tertentu
  • Deserialisasi zero-copy berbasis rkyv memungkinkan data cache digunakan langsung tanpa penyalinan
  • Struktur konkurensi tanpa lock memungkinkan akses paralel yang aman
  • Tanpa inisialisasi interpreter: uv adalah biner statis tunggal, sehingga biaya pembuatan proses Python seperti pada pip hilang
  • Informasi versi dikompresi ke bilangan bulat u64, sehingga operasi perbandingan dan hashing bisa berjalan lebih cepat
• Elemen-elemen ini memang meningkatkan performa, tetapi bukan penyebab utama seluruh peningkatan kecepatan

Pelajaran utamanya

• Kecepatan uv bukan karena Rust, melainkan karena hal-hal yang tidak dilakukannya
• Standardisasi PEP 518·517·621·658 menyiapkan fondasi untuk manajemen paket yang cepat, dan uv mewujudkannya lewat penghapusan legacy dan asumsi modern
• pip juga bisa menerapkan unduhan paralel, cache global, dan resolusi berbasis metadata, tetapi pemeliharaan kompatibilitas mundur selama 15 tahun menjadi hambatan
• Akibatnya, pip pada dasarnya akan selalu lebih lambat, dan hanya alat yang berangkat dari asumsi baru yang bisa mencapai peningkatan kecepatan mendasar
• Pelajaran untuk manajer paket lain adalah bahwa metadata statis, penelusuran dependensi tanpa eksekusi kode, dan struktur yang bisa diresolusikan lebih dulu merupakan syarat penting
• Cargo dan npm sudah mengadopsi pendekatan ini, dan ekosistem yang harus mengeksekusi kode untuk memeriksa dependensi pada dasarnya akan lambat

[GN⁺]

Komentar Hacker News

• Saya rasa tulisan ini menjelaskan kinerja uv dengan baik dari berbagai sudut
  Fakta bahwa uv ditulis dengan Rust memang membantu, tetapi upaya standardisasi selama 10 tahun terakhir yang membuat ekosistem Python lepas dari ketergantungan pada setup.py tampaknya berperan jauh lebih besar

  • Dulu saat mengerjakan proyek Haskell, kelebihannya bukan hanya bahasanya, tetapi juga karena bisa memilih komunitas ahli
    Rust juga layak dipilih karena alasan serupa, yaitu mampu mengangkat kualitas komunitasnya
  • Banyak proyek rewrite ke Rust mendapat efek halo seperti ini
    Mereka bisa meninjau ulang trial and error lama sambil membuat desain yang lebih baik, lalu ditambah keunggulan Rust sendiri menjadi semacam “pukulan satu-dua”

• Saya setuju dengan pendapat bahwa “uv cepat bukan karena ditulis dengan Rust, tetapi karena ada banyak hal yang tidak dilakukannya”
  Namun saya rasa masih terlalu dini untuk memastikan faktor kecepatan tanpa benchmark
  Dampak PEP 518, 517, 621, dan 658 memang besar, tetapi saya ragu seberapa besar kontribusi penghapusan kompatibilitas lama
  Tulisan itu juga tidak membahas bagaimana pilihan bahasa memengaruhi optimisasi
  Menarik juga bahwa parser TOML milik Cargo jauh lebih cepat daripada yang ada di Python

  • Membandingkan pip versi lama dan versi sekarang juga bisa menjadi semacam benchmark
    Memang TOML hanya dibaca saat build jadi porsinya tidak besar, tetapi adopsi wheel ikut berkontribusi pada peningkatan kecepatan
    Referensi terkait: setup.py deprecated, wheels are faster

• Zero-copy deserialization dengan rkyv bukan teknologi eksklusif Rust
  Ini juga bisa dilakukan di bahasa tingkat rendah seperti C/C++

  • Saya memahami maksud “khusus Rust” di sini sebagai “tidak mungkin dilakukan di Python”
    Pernyataan “tidak ada startup interpreter” juga berada dalam konteks yang sama
  • Karena zero-copy sulit diwujudkan di Python, saya akui Rust membuat hal ini aman dan mudah dilakukan
  • Pada akhirnya diskusi ini memang perbandingan Rust vs Python

• Isi tulisannya bagus, tetapi gaya yang dipoles LLM terasa terlalu artifisial
  Mungkin suatu hari akan datang masa ketika orang memulihkan tulisan yang dirusak LLM agar kembali terasa manusiawi

  • Penulisnya juga pernah muncul di HN lewat tulisan tentang SBOM dan Lockfile
    Ia tampak seperti pakar keamanan rantai pasok, tetapi tulisan itu pun terasa berubah oleh gaya samar khas LLM
  • Sebaliknya, ada juga yang sama sekali tidak mencium nuansa LLM dan menganggapnya natural
  • Sekarang kalau saya mencium bau AI dalam tulisan, saya langsung menutupnya
    Prompt yang kaku membuat semua tulisan terdengar mirip, dan sayang rasanya ketika internet terdengar dengan satu suara yang sama

• Saya tidak begitu paham kenapa orang begitu antusias dengan kecepatan uv
  Kebanyakan pengguna Python mungkin bahkan tidak menempatkan kecepatan instalasi paket dalam 10 besar kekhawatiran mereka
  Saya sendiri memakai Python setiap hari, tetapi dampaknya tidak terlalu terasa

  • Di perusahaan lama, update dependensi dengan poetry bisa memakan waktu 5 sampai 30 menit
    Kalau gagal, harus menunggu 30 menit lagi, jadi uv benar-benar memberi pengalaman yang menyenangkan
  • Saya sudah memakai Python lebih dari 20 tahun, dan pip install sering mengambil porsi besar dari waktu deployment
    Saya menghabiskan banyak waktu mencoba mempercepatnya dengan caching
  • Di aplikasi monolitik kerja saya, poetry install butuh 2 menit, sedangkan uv sync selesai dalam beberapa detik
    Menghemat 2 menit di setiap CI memberi efek akumulatif yang besar
  • Saat menjalankan uvx sometool pun, pembuatan virtual environment dan instalasi dependensi selesai dalam beberapa detik, jadi alur kerja benar-benar berubah
  • Sebagai pengguna Python lama, kecepatan uv terasa seperti “peningkatan kualitas hidup”
    Sekarang rasanya sulit kembali ke proyek tanpa uv

• Sebagian teknik optimisasi kecepatan uv tampaknya bisa dipindahkan ke pip
  Misalnya: download paralel, pembuatan .pyc yang ditunda, mengabaikan egg, pemeriksaan versi, dan sebagainya
  Namun uv menangani venv dengan sangat baik sehingga rasanya tidak terlalu perlu membenahi pip
  Pada akhirnya, karena jelas “bukan hanya berkat Rust”, masih ada ruang bagi pip untuk menjadi lebih cepat

• Programmer yang memilih bahasa cepat sering kali memang sudah punya mindset optimisasi performa
  Yang lebih menentukan kinerja sering kali bukan bahasanya, melainkan sikap seperti itu

• Menarik bahwa uv mengabaikan batas atas python<4.0
  Kebanyakan paket menetapkannya secara defensif karena khawatir akan rusak di Python 4, padahal kemungkinan besar sebenarnya tidak masalah
  Pembatasan batas atas itu lebih merupakan upaya menyelesaikan masalah hipotetis daripada masalah nyata

  • Sepertinya uv tidak mengabaikan semua batas atas, melainkan hanya khusus 4.0
    Batasan seperti python<3.0 tetap penting, jadi kasus seperti itu memang harus diblokir

• PEP 658 diterapkan pada 2023 dan uv muncul pada 2024 jelas bukan kebetulan
  Ekosistemnya sudah siap, sehingga alat seperti uv menjadi mungkin
  Namun saya penasaran kenapa para maintainer paket mau menerima perubahan ini
  Pasti ada juga yang merasa setup.py sudah bekerja baik, jadi apa motivasi mereka pindah ke pyproject.toml

  • Faktanya, setup.py memang tidak nyaman bagi banyak orang
    Misalnya, bahkan Requests pun sampai sekarang belum sepenuhnya kompatibel dengan PEP 517/518/621
    Setelah satu setengah tahun, minor release masih tertunda, dan selama itu juga muncul masalah build
  • Karena deklarasi statis lebih aman dan menguntungkan secara performa
    Meski begitu, tetap muncul pertanyaan kenapa pip belum memanfaatkannya dengan maksimal

• Ungkapan “jalur kode yang tidak dijalankan tidak perlu ditunggu” terasa kurang tepat
  Hanya kode yang benar-benar tidak dieksekusi yang bisa menghemat waktu
  Misalnya, meski tidak ada dukungan .egg, kalau format itu memang sudah ditinggalkan maka dampaknya ke kecepatan nyaris tidak ada
  Akan lebih baik kalau ada data kuantitatif tentang item mana yang menghemat waktu dan seberapa besar
  Meski begitu, secara keseluruhan ini tetap tulisan yang tersusun dengan baik