Rye: Pengalaman Python tanpa kerumitan

• Rye adalah alat manajemen proyek dan paket yang ditujukan untuk menangani instalasi Python, proyek pyproject.toml, dependensi, virtualenv, dan instalasi alat global di satu tempat
• Saat ini pengembangannya telah dihentikan, dan penggunaan uv, proyek penerus yang dibuat oleh para maintainer yang sama, direkomendasikan
• Pengguna lama dapat bermigrasi dengan merujuk ke uv migration guide, dan meskipun Rye masih bisa diunduh, tidak ada rencana pembaruan lebih lanjut
• Penghentian pembaruan ini juga mencakup pembaruan keamanan, sehingga untuk proyek baru atau lingkungan pemeliharaan jangka panjang, perlu mempertimbangkan beralih ke uv
• Pengalaman Python terintegrasi yang dituju Rye mencakup proyek kompleks hingga monorepo, tetapi fokus pemeliharaan kini telah berpindah ke uv

---

Status Rye saat ini

• Penghentian pengembangan dan rekomendasi uv

  • Semua pengguna direkomendasikan untuk menggunakan uv
  • uv adalah proyek penerus yang dibuat oleh para maintainer yang sama
  • uv dikelola secara aktif dan digunakan jauh lebih luas dibandingkan Rye
  • Pengguna Rye yang sudah ada dapat merujuk ke uv migration guide
  • Rye masih dapat digunakan, tetapi tidak ada rencana pembaruan tambahan
  • Tidak ada rencana untuk pembaruan keamanan juga

Fitur yang disediakan Rye

• Rye adalah solusi manajemen proyek dan paket untuk Python
• Dibuat dengan tujuan menjadi alat serba ada bagi pengguna Python
• Dalam satu pengalaman terintegrasi, alat ini menangani pekerjaan berikut
  • Manajemen instalasi Python
  • Manajemen proyek berbasis pyproject.toml
  • Manajemen dependensi
  • Manajemen virtualenv
  • Instalasi alat global
• Dirancang agar dapat menangani proyek kompleks dan monorepo
• Video pengantar dapat ditonton di Watch an introduction

[lum7671]

Sudah agak lama, tetapi setelah mencoba ini-itu,
saya menggunakan
Introduction - PDM
.

Sepertinya saya juga harus mencoba menggunakan Rye.

[GN⁺]

Komentar di Hacker News

• Sebagian besar pengembangan packaging inti kini berlangsung di uv, dan Rye menggunakan uv secara internal, jadi ketika uv membaik, Rye juga ikut membaik
  Misalnya, baru-baru ini uv menambahkan resolusi dependensi universal, sehingga kini bisa membuat requirements.txt terkunci dengan satu hasil resolusi yang berjalan di semua platform dan sistem operasi, bukan hanya sistem yang sedang dijalankan, dan Rye terbaru juga mendukungnya
  https://github.com/astral-sh/uv
  Karena saya mengembangkan Rye dan uv, kalau ada pertanyaan saya bisa menjawabnya

  • Saya penasaran apakah resolusi dependensi universal di Rye/UV juga bekerja dengan benar untuk PyTorch, atau mengalami masalah yang sama seperti Poetry
    https://github.com/python-poetry/poetry/issues/6409
    https://news.ycombinator.com/item?id=39257501
  • Saya penasaran apakah ada pekerjaan atau rencana yang bisa diikuti untuk lock file lintas platform
    Salah satu alasan tim saya masih ragu untuk pindah adalah bagian ini. Karena kami mengerjakan ML, jika mengambil proyek berbasis PyTorch sebagai contoh, kondisi yang kami inginkan adalah menaruh semua dependensi di pyproject.toml lalu dari Mac AArch64 atau workstation Windows AMD64 dapat membuat lock file untuk konfigurasi platform berikut: Mac yang memakai PyTorch MPS bawaan, Windows yang memakai PyTorch CUDA, Linux AArch64 yang memakai PyTorch CPU, Linux AMD64 yang memakai PyTorch CPU, dan Linux AMD64 yang memakai PyTorch CUDA
    Terima kasih sudah membuat Ruff; kami sangat puas baik dengan linting maupun formatting-nya
  • Kerja yang luar biasa. Dulu saya kadang harus menyiapkan lingkungan kerja proyek di komputer baru, dan pyenv+venv+pip selalu menyakitkan, tetapi sekarang saya sudah pindah ke Rye
    Sekarang cukup instal Rye, ambil dari GitHub, ketik rye sync, selesai
  • Kalau Anda menangani uv dan rye sekaligus, saya penasaran mengapa keduanya dipertahankan bersamaan. Untuk menghindari kebingungan akibat fragmentasi dan beban memilih, rasanya lebih baik menghentikan rye sekarang
  • Banyak perusahaan yang mementingkan build yang bisa diprediksi dan berperforma baik mulai beralih, dan dalam prosesnya mereka sering perlu membuat SBOM untuk dimasukkan ke alat seperti guac
    https://guac.sh/
    https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
    Berkat fitur pelepasan pin dependensi yang baru ditambahkan, selama pengembangan kita bisa didorong untuk menjaga kompatibilitas, lalu menghasilkan requirements.txt yang akurat dan eksplisit demi reproduksibilitas, sehingga pengelolaan kerentanan dan tahap SBOM menjadi jauh lebih mudah dibandingkan alat seperti Poetry
    Karena alasan serupa saya memakai https://hatch.pypa.io/latest/why/, dan saya juga suka karena cocok dengan uv

• Hal yang membuat saya enggan terhadap Rye adalah bagian yang sangat menganjurkan penggunaan build Python nonstandar
  Halaman filosofinya (https://rye.astral.sh/philosophy/) menjelaskan bahwa build CPython dari python.org sama sekali tidak memadai; tergantung platform hanya ada installer .msi atau hanya tarball; dan berbagai distribusi Python sangat bercabang sehingga menimbulkan segala macam masalah di ekosistem turunannya. Karena itu proyek ini memakai build standalone indygreg, dan berharap suatu hari ada build Python yang dikelola dengan baik dan tepercaya untuk menggantikan kekacauan saat ini
  Informasi tentang build indygreg itu ada di https://gregoryszorc.com/docs/python-build-standalone/main/, dan memilih Python lain juga dimungkinkan: https://rye.astral.sh/guide/toolchains/
  Namun saya hampir tidak pernah mengalami masalah yang mereka sebutkan. Build Python resmi yang saya dapat dari python.org berjalan, Python biasa yang dipasang lewat package manager distro juga berjalan, dan Python yang disertakan dalam image container Docker resmi juga berjalan
  Build khusus itu mungkin juga berjalan baik, tetapi ketidakstandarannya membuat saya ragu. Bahkan ada daftar keanehan perilaku; saya tidak paham mengapa menambahkan keanehan pada sesuatu yang tidak bermasalah. Filosofi Rye yang terlalu agresif dalam memakai build tersebut juga membuatnya kurang menarik dibandingkan alternatif yang secara default memakai Python yang sudah ada di sistem operasi

  • Mungkin yang dimaksud adalah situasi seperti ini: Anda bekerja di perusahaan yang memakai sesuatu seperti CentOS lama, package manager sistem tidak menyediakan yang lebih baru dari Python 3.6, dan binary resmi dari python.org saat dijalankan mencetak error yang sulit dipahami tentang versi glibc
    Untuk membangun Python dari source diperlukan dependensi sistem baru, memakan waktu lama, dan pada akhirnya muncul error yang lebih tidak jelas tentang file header yang hilang. Saat mencari error itu, Anda menemukan flag ./configure untuk mengakali masalah yang sudah diperbaiki upstream GCC pada 2017, dan akhirnya memang berhasil
    Jika Anda belum pernah mengalami tiga jenis error seperti ini atau lingkungan build manylinux, berarti Anda telah sepenuhnya terhindar dari dunia penderitaan. Hal yang sama juga berlaku untuk scripting instalasi Windows atau bagian seperti “pembatasan instruksi CPU yang tersedia” di halaman itu
  • Dalam build, packaging, dan distribusi Python ada dua ekstrem. Yang satu adalah jalan raya, dan yang lainnya adalah koridor dengan seribu mata pisau. Jika Anda tidak memahami usulan Python portabel, berarti Anda beruntung, dan itu artinya Anda terus berada di jalan raya

• Mengunduh kode sumber Python secara berkala, mengompilasinya dengan optimasi produksi standar, lalu memasangnya di /use/local/python${version}; sejak Python 3.7 dirilis pada 2018, ini berjalan sangat konsisten
  Berdasarkan pengalaman saya, perintah-perintah ini begitu stabil dan konsisten sampai layak diotomatisasi. Saya penasaran bagian mana yang dipersoalkan penulis, atau apa keberatan mendasarnya

  • Pernyataan bahwa “build CPython dari python.org benar-benar tidak memadai” mungkin berarti tidak adanya binary macOS/Windows untuk rilis keamanan versi Python lama
    Misalnya, berkas instalasi Python 3.10.14 tidak bisa diunduh, dan berkas instalasi Windows terakhir adalah Python 3.10.11, versi 5 April 2023
  • Setuju. Seharusnya mendukung PSF; mengklaim ada “cara yang benar” yang baru adalah posisi yang aneh

• Saya suka Rye. Ia melakukan persis apa yang dijanjikannya, benar-benar membuat seluruh proses venv/versi Python/packaging terasa nyaman, dan bagi orang yang akrab dengan cara penggunaan Python resmi seperti pyproject.toml, rasanya hampir transparan
  Selain itu, ia membuat Python terasa seperti Cargo, dan Cargo juga alat yang enak dipakai

  • Jika seperti saya Anda mengabaikan alat sejenis Poetry dan tetap memakai pip-tools, uv yang dipakai di dalam Rye bisa menjadi pengganti langsung
    Secara pribadi, saya melihat pip-tools memiliki desain yang jauh lebih baik daripada Poetry atau Pipenv. Ia ortogonal terhadap pip maupun virtualenv, karena keduanya sudah lama menjadi alur yang termasuk dalam Python. Rye bisa dilihat sebagai bukti bahwa pendekatan patuh standar yang terus diperbaiki akhirnya menang
    Selain peningkatan kecepatan berkat Rust, saya suka karena ia memberi default yang tepat tentang di mana menaruh virtual environment (.venv) dan bagaimana memasang beberapa versi Python. Kelihatannya kecil, tetapi setelah wheel menyelesaikan masalah instalasi numpy, default yang masuk akal seperti ini dan pip-tools bawaan pada dasarnya adalah semua yang masih kurang. Dalam arti itu, saya juga penasaran apa alasan keberadaan Anaconda setelah binary wheel muncul
  • Saya mulai memakai Python karena mendengar bahwa ada satu cara untuk melakukan segala hal, tetapi pengalaman instalasi dan manajemen environment-nya kacau balau
    Senang melihatnya akhirnya membaik
  • Kalau “membuat Python terasa seperti Cargo”, saya langsung terbujuk. Poetry menghabiskan seharian penuh dan tetap tidak bisa menyelesaikan dependensi, jadi saya sedang mempertimbangkan mencoba pixi
    Rasanya package manager Python lebih banyak daripada aplikasi chat Google
  • Saya penasaran apa maksud “benar-benar membuatnya nyaman”. Apakah terlalu sulit untuk diringkas? Saya tidak benar-benar menemukan bagian yang terasa sebagai pilihan khusus dari sisi pengalaman pengguna di Anaconda atau Poetry
    Dan dari sisi kurasi, saran untuk memercayai organisasi kecil dibanding organisasi yang lebih besar dan lebih lama tampak sulit meyakinkan. Jadi saya penasaran apa sebenarnya hal yang dijanjikannya. Yang bisa saya baca kira-kira hanya “package manager yang bagus itu bagus, cepat, dan bagus”, jadi akan menyenangkan kalau ada halaman perbandingan atau filosofi

• Sinisme di HN kadang mengejutkan
  Saya suka Rye. Setelah memakai package manager bahasa lain seperti Cargo atau Hex, saya selalu merasa sayang Python tidak punya sistem serupa, dan Rye benar-benar mengobati rasa haus itu. Dari sudut pandang saya yang tidak ingin memasang banyak alat untuk mengelola venv, versi Python, dan dependensi proyek, sangat menyenangkan karena Rye saja bisa menangani semuanya

  • Penasaran apakah Anda pernah mencoba conda. Bagaimana Rye dibandingkan dengan conda?
    Saya belum begitu paham Rye, tetapi conda juga bisa mengelola venv, versi Python, dan dependensi proyek dengan baik
  • Setuju. Rye berjalan baik untuk saya. Saya menginginkan Cargo untuk Python, dan sejauh ini dari sudut pandang saya Rye berhasil mencapainya

• Bertemu dependency manager Python baru rasanya seperti tanpa sengaja menemukan framework JavaScript baru

  • Filosofi saya sederhana. Kalau harus menjadi program yang bisa didistribusikan, pakai saja Go; kalau tidak perlu hal seperti port, pakai Docker; dan kalau tim IT atau seseorang memberi Anda komputer dengan sistem operasi serta versi Python yang dipakai semua orang di organisasi, pakai venv saja
    Kalau harus berurusan dengan port, harus mendistribusikan program, atau library bergantung pada C atau komponen sistem operasi, lebih baik mulai pekerjaan konsultasi berbayar di mana setelah dibayar Anda tidak perlu mengelola codebase atau bertanggung jawab atasnya
  • Benar. Docker sudah menyelesaikan masalah distribusi dan eksekusi program Python sekitar 10 tahun lalu
    Sekarang CUDA dan PyTorch juga bisa dijalankan di Docker. Dalam thread seperti ini, ketika seseorang berkata “pakai Docker saja”, jawaban yang sering muncul adalah “saya tidak mau belajar Docker”, padahal meski sama sekali tidak punya pengalaman Docker, menyalakan container Python hanya butuh 10 menit
  • Benar. Tapi tidak seperti Poetry dan sejenisnya, yang satu ini benar-benar bagus
  • Ini benar-benar parah. Dari sisi pengguna, menjengkelkan bahwa setelah bertahun-tahun sebanyak ini masih belum ada standar

• pixi(https://pixi.sh/latest/) bagus. Bisa mengunci versi Python dan memasang paket dari conda maupun PyPI, serta ditulis dengan Rust

  • Terlihat menarik, tetapi rasanya sulit untuk benar-benar berinvestasi lagi di ekosistem lain. Cara yang meminta mengambil dengan curl lalu mem-pipe ke bash, kemudian eval pada output perintah arbitrer terasa memberatkan
  • Terima kasih untuk tautannya. Penasaran apakah lebih cepat daripada conda
  • pixi hebat. Kalau Anda pengguna conda, pixi bisa dipakai sebagai pengganti conda yang menaruh environment yang terhubung dengan Git/direktori proyek, mirip devbox/devenv/flox
    Latar belakangnya agak rumit. Perusahaan Anaconda punya conda yang ditulis dengan Python, dan ekosistem open source conda-forge adalah channel conda dengan bot build CI. Setelah itu, di bawah payung conda-forge yang sama, mamba yang ditulis dengan C++ muncul sebagai pengganti conda, dan ini adalah pengganti drop-in sungguhan sampai level alias conda=mamba seharusnya berfungsi. Sekarang conda juga memakai libmamba sebagai resolver untuk meningkatkan kecepatan
    Kemudian penulis mamba memisahkannya menjadi pixi, menulis ulang dengan Rust, dan mengubah filosofi tentang lokasi environment serta cara aktivasi, tetapi tetap sepenuhnya kompatibel dengan environment conda

conda selalu mendukung instalasi paket PyPI melalui pip ketika paket tersebut tidak ada di channel conda, dan pixi mendukung paket PyPI melalui uv. Karena itu pixi cepat. Menurut artikel blognya, ada juga optimisasi lain yang membuatnya jauh lebih cepat daripada mamba
Jika memakai paket yang bukan Python murni, keluarga conda adalah pilihan yang tepat. Pilihan manajer paket (conda/mamba/pixi) bersifat sekunder
Masalah PyPI adalah kurangnya peran penjaga gerbang. Ditambah lagi kurangnya cara standar untuk memaketkan paket yang bukan Python murni, sehingga environment bisa bocor, atau menjadi tidak dapat direproduksi terutama ketika hanya mendistribusikan source lalu melakukan hal aneh seperti mem-bootstrap environment di setup.py sampai menyertakan compiler
Di sisi conda, channel conda-forge melakukan kontrol kualitas yang cukup baik. Mereka memeriksa constraint, lisensi, masalah file lisensi yang hilang dari distribusi PyPI, isolasi environment, dan sebagainya. Tentu saja tidak sempurna, karena maintainer bisa menggunakan bot resmi yang otomatis me-merge perubahan PyPI dengan constraint versi yang salah
Masalah yang saat ini belum bisa diselesaikan oleh alat mana pun berpusat pada PyPI. Kita harus menangani paket yang tidak ada di conda, dan rilis paket pada praktiknya juga dipaksa dilakukan terlebih dahulu ke PyPI
Bahkan saat menginstal paket yang hanya ada di PyPI melalui conda, sebagian dependensinya bisa saja ada di conda. Sejauh yang saya tahu, tidak ada manajer paket yang memakai paket conda untuk memenuhi dependensi paket PyPI. Kita bisa menambahkan paket conda secara manual untuk mencocokkan dependensi, tetapi ada risiko tidak mendapatkan constraint versi yang benar
Saat menulis paket Python open source pun, meski konfigurasinya hanya bergantung pada channel conda, kebanyakan harus atau sebaiknya dirilis terlebih dahulu ke PyPI. Ini karena rilis channel conda-forge pada praktiknya mengharuskan keberadaan di PyPI. Jadi bagi orang seperti saya pun, Rye masih bisa berguna dan layak dicoba

• Perlu diketahui bahwa orang-orang di balik uv (https://astral.sh/blog/uv) telah mengambil alih tongkat komando proyek Armin ini
• Di halaman perkenalannya tertulis, “Rye is still a very experimental tool, but this guide is here to help you get started.”
  Proyek ini sangat menjanjikan, tetapi saya berencana menunggu sampai mencapai tahap yang lebih matang. Saya menyukai semua hal lain yang dibuat tim Astral, jadi ekspektasinya tinggi
• Kami menggunakan rye untuk pengembangan library openai-python, dan pengalamannya sangat baik
• Rye terlihat bagus dan Poetry juga cukup menyenangkan untuk dipakai, tetapi saya benar-benar jadi menghargai kualitas tooling bawaan Go
  Setiap kali memulai proyek Python, rasanya harus mempelajari lagi kondisi terbaru pengelolaan dependensi/virtual environment