Rye dan uv: Agustus adalah musim panen packaging Python

• Setelah pengelolaan Rye berpindah ke Astral pada Februari 2024, uv sebagai resolver dan installer dasarnya berkembang pesat dan muncul sebagai kandidat penyatu alat packaging Python
• uv terbaru kini mencakup manipulasi pyproject.toml, dukungan workspace, referensi paket lokal, instalasi skrip, hingga pengelolaan instalasi Python, sehingga terus menyerap peran yang sebelumnya ditangani Rye
• Investasi di AI dan ML menambah jumlah pengguna baru Python, tetapi banyaknya pilihan alat packaging dan kompatibilitas yang tidak seragam membuat pengalaman pengembang masih belum konsisten
• Ekosistem packaging membutuhkan alat dominan yang dipakai semua orang agar investasi dan dokumentasi terkonsentrasi pada satu stack, dan Rye sangat mungkin menjadi jalur migrasi menuju peralihan yang berpusat pada uv
• Investasi VC di Astral adalah risiko yang perlu dipertimbangkan PSF dan proyek inti Python, tetapi uv dinilai sebagai kode yang bahkan dalam skenario terburuk pun masih bisa di-fork dan dipelihara

---

Arus konsolidasi fitur dari Rye ke uv

• Pada Februari 2024, pengelolaan Rye berpindah ke Astral, dan dalam beberapa bulan setelahnya Astral dengan cepat meningkatkan alat packaging Python
• Pengguna Rye bisa merasakan bahwa uv sebagai resolver dan installer dasarnya menjadi lebih baik dan lebih cepat
• uv terbaru mulai menyediakan langsung fitur-fitur yang sebelumnya memerlukan Rye
  • manipulasi berkas pyproject.toml
  • dukungan workspace
  • referensi paket lokal
  • instalasi skrip
  • pengelolaan instalasi Python
• Pengguna yang saat ini memakai Rye perlu melihat uv dan memberi umpan balik kepada Astral

Mengapa alat packaging Python perlu terkonsolidasi

• Presentasi di EuroPython Prague berfokus pada kondisi terkini packaging Python dan pelajaran yang didapat saat membuat Rye
• Tujuan alat packaging adalah menjadi alat yang mendominasi bidang tersebut
  • alat yang dipakai semua orang seharusnya adalah alat terbaik
  • karena itulah alat pertama yang ditemui orang saat memulai perjalanan pemrograman dengan Python
• Dalam dua tahun terakhir, Python menjadi platform yang sangat panas dan populer bagi pengembang baru berkat investasi dan minat pada AI dan ML
• Penting agar pengguna baru mengingat Python bukan sebagai bahasa yang usang dengan alat yang buruk, melainkan sebagai bahasa dengan pengalaman pengembang yang unggul
• Namun saat ini packaging Python masih memiliki terlalu banyak pilihan, kompatibilitas antaratlat belum sepenuhnya baik, dan berbagai ketidakkonsistenan mengganggu pengalaman
  • sebagian pengguna mengikuti satu alat lalu mentok, memindahkan seluruh stack ke conda, lalu kembali lagi

Potensi uv menjadi alat dominan

• Ketika sebuah alat menempati posisi dominan, itu berarti sebagian besar investasi terkonsentrasi pada satu stack
• Akan lebih ideal bila Rye dan berbagai alat di sekitarnya tidak lagi perlu berdiri sendiri setelah alat dominan itu terbentuk
• Saat ini uv dinilai sebagai alat yang paling berpeluang mengambil peran tersebut
  • masih belum memenuhi semua use case
  • namun tampaknya akan cepat mencapai titik itu
• Sekarang adalah saatnya komunitas mulai berkumpul di sekitar uv
• Ini bukan berarti alat tersebut akan selamanya menjadi satu-satunya alat
  • alat bisa muncul dan hilang
  • di masa depan bisa saja ada alat lain

Pensiunnya Rye dan perubahan panduan proyek Python

• Rilis final Rye yang diharapkan akan memensiunkan fitur khas Rye, memigrasikan pengguna ke uv, dan pada dasarnya bertindak seperti alias untuk uv
• Hanya memensiunkan satu alat, yakni Rye, tidaklah cukup
  • saat ini Python memakai beberapa solusi manajemen paket
  • komunitas perlu mengarahkan orang ke lebih sedikit alat
• Rye dan uv dibangun di atas perkembangan panjang ekosistem di bawahnya
  • perpindahan dari setup.py ke eggs, lalu ke wheels
  • perpindahan dari ketiadaan standar metadata ke keberadaan standar
  • perpindahan dari build system yang terikat menjadi build system terpisah
  • pekerjaan yang memungkinkan biner Python dapat didistribusikan ulang dan diunduh
  • ekosistem Rust crates dan pustaka Python terkait
• Komunitas perlu siap untuk suatu saat mengatakan bahwa beberapa alat tidak lagi direkomendasikan
  • dulu dokumen panduan bagi pengembang baru merekomendasikan ez_setup.py dan easy_install
  • kemudian ez_setup.py dihapus dari dokumen panduan dan digantikan pip
  • beberapa proyek membimbing pengguna dengan pip-tools, poetry, dan PDM
  • saat ini banyak proyek bahkan menampilkan lima panduan instalasi sekaligus karena banyaknya alat
• Pemelihara proyek Python yang penting perlu mencoba uv secara langsung dan menilai apakah mereka bisa mengarahkan pengguna ke uv
• Tulisan Charlie dari Astral tentang apa yang saat ini bisa dilakukan uv menunjukkan capaian uv saat ini

Investasi VC Astral dan risiko bagi komunitas

• Fakta bahwa Astral, pembuat uv, adalah perusahaan yang menerima investasi VC adalah isu yang tak terhindarkan
• Dari sudut pandang komunitas, masuknya dana besar oleh seseorang dapat menciptakan tantangan baru
• PSF dan proyek inti Python perlu mempertimbangkan hal ini
• Melihat kode dan perilaku uv, alat ini tampak bisa di-fork dan dipelihara bahkan dalam masa depan terburuk sekalipun
• Bahkan jika Astral tutup atau melakukan hal yang sangat meragukan dari sisi lisensi, komunitas mungkin tetap berada pada posisi yang lebih baik daripada sebelum uv ada

[GN⁺]

Pendapat di Hacker News

• Rilis terbaru uv juga dibahas kemarin: https://news.ycombinator.com/item?id=41302475
  Tulisan yang ditautkan adalah pandangan yang ditulis oleh pembuat Rye setelah melihat rilis tersebut

• Bagi yang tertarik dengan uv, penggunaan uv sebagai pengganti pip membuat proses rilis Home Assistant jauh lebih cepat
  Waktu yang dibutuhkan untuk rilis berkurang dari sekitar 2,5 jam menjadi sekitar 20 menit, dan detailnya ada di https://developers.home-assistant.io/blog/2024/04/03/build-i.... Sebagai catatan, saya hanya pengguna HA

  • Saya tidak paham bagaimana pip bisa memakan waktu lebih dari 1 jam untuk membuat image, padahal ini bukan bahasa yang dikompilasi
    Saya memang hanya memakai Python secara ringan, tetapi saya tidak tahu apa yang sebenarnya dilakukan sampai selama itu, dan rasanya tidak masuk akal

• Saya tahu packaging Python memang bermasalah, tetapi secara pribadi sejauh ini saya sudah bisa melangkah cukup jauh hanya dengan plain pip
  Perubahan terbesar adalah beralih dari virtualenv asli ke modul venv bawaan. Kalau harus benar-benar serius mengelola dependensi, saya mungkin akan membuat monorepo ala FAANG dan menghindari kerepotan yang berkaitan dengan package manager

  • Saya sangat menyarankan untuk mencoba sendiri monorepo
    Saya mengelola monorepo Python di lingkungan produksi dan manajemen dependensinya seperti neraka. Saya mencoba menerapkan beberapa fitur baru Poetry, tetapi kondisi ekosistem di sekitar monorepo besar sangat buruk
  • Masalah ini perlu dipikirkan lebih dalam
    Targetnya bukan “cukup untuk saya”, melainkan dibutuhkannya tool standar untuk package dan virtual environment yang bisa diskalakan dari organisasi dengan 2 developer Python hingga ratusan atau ribuan orang. Kalau tidak, ekosistem akan terpecah, bug dan dokumentasi yang sulit akan bertambah, dan bahasa ini akan sulit terus berkembang secara efektif
  • Kalau tidak perlu peduli pada versi Python, menurut saya pip + venv juga sudah cukup
    Namun tidak ada cara untuk mendefinisikan sebuah proyek dibuat dengan basis versi Python apa. Jika membuat package, besar kemungkinan perlu mengujinya terhadap beberapa versi, dan jika itu bukan package distribusi yang dapat diinstal melainkan sekumpulan kode yang dibagikan oleh beberapa developer, untuk pekerjaan seperti menjalankan model machine learning, men-deploy cloud function, atau membuat laporan, biasanya orang ingin menargetkan tepat satu versi Python saja
    Saya juga bertanya-tanya apakah pendekatan monorepo berarti menyalin numpy dan pandas ke dalam repository
  • Pengalaman saya sepenuhnya sama: pip sudah cukup bagi saya

• Awalnya saya berharap tool baru ini akan menyelesaikan masalah “packaging” Python, tetapi setelah membaca lebih lanjut, ternyata ini lebih tentang manajemen package daripada masalah membungkus aplikasi Python yang saya buat
  Secara pribadi saya tidak pernah punya masalah besar dengan manajemen package Python, dan meski ekosistemnya punya kekurangan, selain hal seperti tidak adanya namespace, pip pada umumnya bekerja dengan baik
  Yang benar-benar menjengkelkan adalah tidak adanya cara mudah untuk membungkus aplikasi Python menjadi executable lalu mendistribusikannya ke suatu tempat. Di lingkungan produksi saya sering melihat git clone dan pembuatan virtualenv dilakukan, yang menuntut konektivitas berlebihan pada server target dan terkadang meninggalkan dependensi pengembangan di sistem operasi. Dari sudut pandang keamanan, itu ide yang sangat buruk, jadi sampai masalah ini terselesaikan, saya akan lebih memilih bahasa lain untuk pekerjaan yang perlu dikirim ke end user atau deployment produksi

  • Pernyataan itu tidak salah, tetapi kalau diurai, intinya adalah perlu membuat orang lain bisa menjalankan aplikasi dengan mudah
    Untuk itu, aplikasi harus dikirimkan ke pengguna, menemukan Python di sana, dan prosesnya harus transparan bagi pengguna. Saat membuat Rye, dan demikian juga dengan uv, salah satu alasannya adalah mencoba mendukung instalasi Python dengan cara yang tidak merusak sistem
    Bentuk yang lebih maju adalah mengotomatiskan seluruh proses, termasuk uv. Bahkan sekarang, jika mau, dengan installer curl to bash, uv/Rye dan aplikasi bisa diinstal ke lokasi sementara khusus aplikasi, sehingga sistem pengguna tidak pernah rusak
    Semoga suatu hari proses ini sepenuhnya transparan, tidak memerlukan akses jaringan, dan juga menyediakan sesuatu seperti .msi untuk Windows. Namun prasyaratnya adalah tool seperti uv harus bisa menempatkan Python yang sudah dikompilasi sebelumnya beserta semua dependensi yang diperlukan secara arbitrer di lokasi yang sesuai untuk platform pengguna
    Bonus akhir yang suatu hari bisa disediakan uv adalah hasil yang sepenuhnya terbungkus, dan itu akan sangat bagus. Bahkan tahap sebelumnya saja sudah bisa membuat pengalaman menyediakan tool command-line yang dibuat dengan Python kepada pengguna tidak lagi mengerikan. Bisa memakai uvx, atau jika mau, uv sendiri bisa disembunyikan sepenuhnya
  • Tergantung apa yang ingin diinstal dan ke mana, tetapi untuk target distribusi yang masuk akal biasanya ada tool untuk membuat binary yang dapat diinstal bagi target tersebut
    Misalnya ada tool yang membuat installer per sistem operasi, dan juga sudah muncul tool untuk mendistribusikan ke tempat yang agak khusus seperti Android, iOS, atau browser. Tentu saja package tertentu mungkin tidak berjalan di target tertentu, tetapi karena ada antarmuka standar, jika kodenya bisa dijalankan di suatu tempat, tool untuk target tersebut semestinya bisa membuat hasil yang berjalan di target itu

• Setelah rug pull berbasis investasi ventura npm, akuisisi oleh Microsoft, dan OpenAI menunjukkan bahwa bahkan status nirlaba legal pun hanyalah pemasaran yang tak berdaya bagi para pemimpin yang terjerat jalur investasi ventura, saya jadi enggan menyerahkan infrastruktur bahasa yang berada di jalur inti kepada organisasi seperti ini
  Para individu yang berkontribusi di sana masing-masing memang hebat, sering kali luar biasa, tetapi kepentingan finansial di tingkat organisasi sudah tercemar sejak awal. Setelah 1–4 tahun, yang penting adalah organisasinya. Kurang lebih seperti “mati sebagai pahlawan, atau hidup cukup lama untuk menjadi penjahat”
  Jadi linter cepat, pemeriksaan tipe, pemindaian kode, dan alat bantu PR masih oke dan bisa diganti kapan saja. Tapi alur instalasi dan repositori paket tidak
  Memang disayangkan jika mengingat kondisi pip dan conda, tetapi menurut saya inilah kenyataannya

  • Di Python, pertarungan itu sudah kalah
    Menurut saya Microsoft memiliki Python, hanya saja tidak menampakkannya secara terbuka
    Beberapa tahun lalu saya ingin membuat binding Python untuk kubectl, tetapi baru tahu bahwa agar bekerja lintas platform, CGo harus memakai compiler yang sama dengan Python di semua platform. Namun di Windows, CGO memakai MINGW sementara Python memakai MSVC. Di mailing list pengembangan Python yang ada saat itu, saya bertanya mengapa proyek “open source” memakai compiler proprietary, dan jawaban yang saya dapat adalah bahwa MSVC adalah pilihan historis dan sekarang tidak bisa diubah. Penjelasannya, Microsoft menyediakan infrastruktur gratis untuk Python Foundation agar bisa menjalankan CI dan build, serta menyediakan developer yang mengerjakan interpreter Python. Dengan kata lain, karyawan Microsoft dibayar oleh Microsoft untuk mengerjakan interpreter Python, dan mereka mendapat instruksi agar tidak mengeluarkan alat Microsoft dari toolchain
    Dari tahun ke tahun situasinya makin buruk. Seperti proyek-proyek serupa, keberhasilan menciptakan lahan bagi orang-orang tanpa kemampuan khusus untuk memegang kekuasaan, dan proyek-proyek di sekitar seperti Python Foundation dan PyPA mulai dipenuhi orang-orang yang naik posisi bukan karena menyumbangkan kode yang berguna, melainkan karena menulis halaman kode etik. Perselisihan tanpa akhir seputar kode etik dan kontrol posisi ini pada akhirnya membuat kontributor lama pergi atau disingkirkan, dan baru-baru ini Tim, pembuat Tim sort, juga dilarang
    Microsoft terus mendorong agenda umum yang mereka lakukan pada setiap proyek yang mereka sentuh. Mereka menambahkan banyak fitur tak berguna demi iklan, membuat proyek terombang-ambing ke segala arah, dan terutama memaksanya sebisa mungkin mengikuti tren. Karena itu Python menambahkan sebanyak mungkin tipe ala machine learning meski merupakan bahasa dengan sistem tipe yang sama sekali berbeda, dan terobsesi pada precompile serta JIT meski bahasa ini setengahnya dipakai untuk menempelkan library native secara dinamis. Pada dasarnya mereka menjadikannya C# tanpa kurung kurawal
    Microsoft cukup cerdas untuk tidak mengiklankan hal ini secara besar-besaran, karena mereka tahu jika kepemilikan Python diumumkan secara terbuka, banyak orang akan menjauh dari teknologinya. Namun mereka terus membuat developer bergantung pada alat mereka, dan suatu hari nanti mereka akan datang untuk menarik kembali investasi itu
  • Bukankah npm memang dari awal sebuah perusahaan? Saya tidak tahu rug pull yang dimaksud itu apa, dan apakah ada sesuatu yang benar-benar berhenti bekerja?
  • Saya tentu sangat menyambut jika PSF dan PyPA sadar lalu mengeluarkan pernyataan yang bagus tentang packaging Python
    Namun sejauh ini yang mereka keluarkan pada dasarnya hanya miliaran posting blog kontributor bernada “sistem yang kami buat membatasi kami sehingga tidak bisa membantu, dan bagaimanapun itu bukan salah kami”
    Mereka tampak terlalu tenggelam dalam sistem internal dan politik internal sampai tidak lagi tahu mengapa mereka ada di sana
    Jadi jika ada pihak yang benar-benar berhasil melakukannya dengan baik dan menguasai pasar seperti Astral, itulah hasil yang memang pantas kita terima sebagai komunitas
    [1]: Yang saya maksud di sini adalah politik internal. Bukan keributan aneh ala ekstrem kanan tentang “perekrutan DEI!”

• Alat-alat ini masih punya masalah otoritas
  Ini berbeda dari cargo karena bukan sesuatu yang disetujui PyPA. Pada saat yang sama, PyPA selama bertahun-tahun gagal menghadirkan solusi menyeluruh, sementara packaging Python dan alat pengembangannya terus bertambah. Baru 3–4 tahun lalu saja, poetry dan pipenv tampak seperti menyelesaikan masalah packaging Python yang tidak terselesaikan oleh pip+virtualenv
  Sekarang menurut saya PyPA harus naik ke kapal astral.sh, tetapi saya tidak tahu apakah mereka akan melakukannya tanpa tingkat kendali tertentu

  • Saya baru-baru ini mengetahui bahwa Authority dalam nama PyPA, Python Packaging Authority, awalnya dimaksudkan sebagai lelucon: https://discuss.python.org/t/remove-the-authority-from-packa...
  • Sejak PyPA menyetujui Pipenv dibanding pilihan lain, saya berhenti memedulikan rekomendasi PyPA
    Menurut saya itu banyak dipengaruhi hubungan pribadi, dan pada saat itu Pipenv adalah bencana. Niatnya baik, tetapi di perusahaan, bahkan pada repositori dengan dependensi populer yang relatif sedikit, kami harus menunggu satu jam untuk memperbarui lock file. Itu benar-benar tidak bekerja
    Secara praktis, saya sangat menghargai kerja teknis sulit yang dilakukan PyPA. Namun saya tidak terlalu peduli paket alat apa yang sekarang mereka rekomendasikan. Menurut saya lebih baik memakai apa yang dipakai komunitas dan tidak perlu mengkhawatirkan usulan “resmi”
  • Dari sudut pandang pengamat yang agak dari luar, tidak mudah memahami apa sebenarnya PyPA itu
    Jumlah pesertanya tidak jelas, dan seberapa terkait PyPA dengan Python inti atau PSF juga tidak pasti
    Menurut saya persetujuan yang benar-benar membantu adalah yang datang dari proyek Python inti itu sendiri. Di dunia ideal, tutorial resmi Python akan dimulai dengan “begini cara menginstal Python” lalu memandu instalasi uv, sama seperti dokumentasi resmi Rust mengarahkan ke rustup dan cargo
    Saya sangat berharap PSF membangun hubungan tertentu dengan Astral sehingga suatu hari kenyataan seperti ini bisa terwujud
  • Jujur saja, pada titik ini saya tidak memedulikan PyPA
    Dalam konteks ini, menurut saya mereka sudah membuktikan sendiri bahwa mereka pada umumnya tidak relevan. Apa pun yang mereka sentuh tampak membusuk, jadi meski menyedihkan, saya berharap mereka menjauh dari masalah ini. Menyakitkan rasanya mengatakan ini dan bertentangan dengan filosofi saya, tetapi ini hanya penilaian yang mencerminkan keadaan saat ini. Saya telah bekerja penuh waktu dengan Python selama 10 tahun, dan ekosistem packaging lain secara praktis sudah mendahului Python lebih dari satu putaran
    Sekarang saya bahkan tidak peduli lagi pada nuansa seperti “apakah ini masalah eksekusi PyPA atau cakupan peran yang ditetapkan memang salah”. Saya juga sudah muak terseret ke pembahasan semacam itu

• Armin mendukung agar uv mendominasi area ini, tetapi juga mengakui bahwa karena berbasis pendanaan ventura, ada kemungkinan terjadi rug pull
  Sebagai solusi untuk potensi masalah itu, ia mengatakan “sangat mudah untuk di-fork”, tetapi bukankah fork pada dasarnya justru melahirkan fragmentasi yang lebih besar? Persis masalah yang ingin ia selesaikan
  Menurut saya, alat yang ingin mendominasi lanskap packaging Python seharusnya digerakkan dan dikendalikan oleh komunitas

  • Fork tidak selalu secara inheren melahirkan fragmentasi yang lebih besar
    Tingkat fragmentasi setelah terlebih dahulu terkonsolidasi pada alat yang kemudian di-rug pull bisa saja jauh lebih rendah daripada sebelum konsolidasi
    Dan apakah komunitas imajiner ini masih butuh beberapa dekade lagi untuk membuat alat dominan yang bagus?
  • Pilihan lisensi MIT atau Apache memang membuatnya mudah di-fork, tetapi pilihan Rust sebenarnya membatasi jumlah orang yang bisa berkontribusi
  • Bukankah npm juga berbasis pendanaan ventura?

• Pagi ini di kantor, karena Poetry lambat, saya melihat kemungkinan memigrasikan software kami dari Poetry ke uv
  Sejauh ini saya banyak membaca dokumentasi, tetapi belum banyak kemajuan nyata. Dulu saya juga yang mengerjakan migrasi ke Poetry, dan waktu itu jauh lebih sederhana. Dari yang saya lihat sejauh ini, Poetry berusaha membuat package manager sederhana yang bekerja seperti package manager lain, sedangkan uv tampaknya tetap mempertahankan cukup banyak kegilaan package Python

  • Setidaknya uv tidak berbenturan dengan virtualenv dan membuat kekacauan total seperti Poetry
    Juga tidak ada perubahan kecil di Poetry yang merusak format package.toml, atau “sources” bodoh yang tidak bekerja untuk dependensi transitif sehingga waktu resolusi di beberapa indeks menjadi lebih lama
  • Bisa berbagi secara spesifik bagian apa yang sulit di uv?
  • Baru-baru ini saya pindah dari pip-tools ke uv, dan cukup mulus
    uv rasanya pada dasarnya langsung cocok dengan alur tooling Python standar
  • Untuk saat ini uv terlalu low-level; mungkin yang Anda inginkan sebenarnya Rye?
  • Kegilaan seperti apa yang dimaksud?

• Saya tidak akan menyalahkan orang jika melewatkan giliran kali ini dan menunggu edisi 2026 dari “Package manager Python: kali ini benar-benar sudah kami selesaikan!”
  Meski begitu, saya tetap pengguna Nix yang puas

• Saya sangat suka framing ini
  Berkat pekerjaan yang dibangun bertahap oleh banyak orang selama waktu yang lama, sekarang kita sampai pada titik di mana beberapa orang di satu perusahaan bisa memperbaiki situasi secara drastis dengan usaha sedang