PYX: Langkah Berikutnya dalam Packaging Python

 (astral.sh)
18 poin oleh GN⁺ 2025-08-14 | 4 komentar | Bagikan ke WhatsApp
  • pyx adalah registry paket native Python yang dibuat oleh tim pengembang uv, yang meningkatkan kecepatan instalasi dari PyPI, PyTorch, dan sumber privat hingga 10x
  • Melampaui cakupan registry paket yang ada, ia menawarkan fitur kecepatan, keamanan, dan kesadaran GPU, serta mendukung paket internal dan sumber publik seperti PyPI dan PyTorch
  • Menyediakan URL indeks khusus yang dapat difilter berdasarkan kriteria seperti popularitas paket, waktu pembuatan, dan ada tidaknya kerentanan untuk memperkuat keamanan dan kepatuhan
  • Melalui dukungan standar terbaru yang dikhususkan untuk Python dan integrasi langsung dengan uv, autentikasi dan penggunaan dapat dilakukan tanpa konfigurasi
  • Menyelesaikan masalah utama di lingkungan enterprise seperti build duplikat dalam tim, sulitnya instalasi PyTorch dan CUDA, build yang rusak, serta kerepotan autentikasi melalui integrasi server-klien
  • Dengan fitur sadar GPU, ia menyediakan versi prebuilt dari PyTorch, vLLM, FlashAttention, DeepSpeed, dan lainnya yang sesuai dengan perangkat keras, dengan metadata yang konsisten dan konfigurasi optimal
  • Memberikan performa yang jauh lebih unggul dibanding registry privat lain melalui artefak yang dioptimalkan dan API metadata native uv

Visi dan Latar Belakang Astral

  • Astral adalah perusahaan yang membuat alat pengembangan berperforma tinggi untuk ekosistem Python, dan dikenal lewat Ruff (linter·formatter) dan uv (package manager)
  • Latar belakang pendiriannya adalah karena mereka merasa bahwa meskipun Python adalah bahasa pemrograman paling populer di dunia, ia belum cukup didukung dari sisi tooling
  • Saat ini rangkaian alat Astral mencatat lebih dari 100 juta instalasi per bulan, dan uv memproses lebih dari 500 juta permintaan per hari, menunjukkan pertumbuhan yang eksplosif
  • Tujuannya adalah menjadikan Python ekosistem pemrograman paling produktif, dan untuk itu mereka ingin membangun cloud Python melampaui alat klien

Pengenalan pyx

  • pyx adalah registry paket native Python yang dirancang sebagai backend yang dioptimalkan untuk uv
    • Dapat meng-host paket internal
    • Berperan sebagai frontend yang dipercepat dan dapat dikonfigurasi untuk sumber publik seperti indeks PyPI dan PyTorch
  • Fitur utama
    • Kecepatan instalasi tinggi : optimasi instalasi dan build paket
      • Saat menginstal paket dari PyPI, PyTorch, atau sumber privat internal, pyx memanfaatkan artefak yang dioptimalkan dan API metadata native uv
      • Menawarkan kecepatan hingga 10x lebih cepat dibanding registry privat lain
    • Peningkatan keamanan dan kepatuhan : meminimalkan risiko melalui pemahaman dependensi dan supply chain
      • Dapat membuat URL indeks khusus untuk pemfilteran paket
      • Mengontrol akses paket berdasarkan kriteria seperti popularitas, usia rilis, dan status kerentanan
      • Menjamin build yang dapat direproduksi di sisi server
    • Dukungan standar terbaru
      • Mendukung standar packaging dan workflow terbaru yang dikhususkan untuk Python
      • Terintegrasi langsung dengan uv sehingga autentikasi dan penggunaan berjalan mulus tanpa konfigurasi tambahan
    • Distribusi paket sadar GPU : menyederhanakan build dan distribusi terkait CUDA dan PyTorch
      • Menyediakan prebuilt kustom untuk library terkait GPU seperti PyTorch, vLLM, FlashAttention, dan DeepSpeed
      • Menjaga konfigurasi optimal berbasis perangkat keras dan metadata yang konsisten

Masalah yang Ingin Diselesaikan

  • Sulitnya instalasi library terkait GPU seperti PyTorch, CUDA, FlashAttention, dan DeepSpeed
  • Pemborosan sumber daya akibat build berulang untuk paket yang sama dalam tim
  • Error build akibat pembaruan setuptools
  • Proses autentikasi registry internal yang merepotkan

Strategi Integrasi Server-Klien

  • Menyelesaikan masalah-masalah di atas secara langsung melalui integrasi vertikal antara uv (klien) dan pyx (server)
  • uv dapat digunakan tanpa pyx, dan pyx juga dapat digunakan tanpa uv, tetapi pengalaman terbaik diberikan saat keduanya digunakan bersama
  • Integrasi mendalam dengan alat open source memungkinkan pengalaman pengembangan yang sebelumnya tidak mungkin diwujudkan

Model Bisnis

  • Alat Astral seperti uv, Ruff, dan ty akan tetap gratis, open source, dan berlisensi permisif selamanya
  • Sebagai gantinya, mereka menyediakan layanan hosting berbayar seperti pyx untuk memenuhi kebutuhan infrastruktur “langkah berikutnya”

Status Saat Ini dan Rencana Mendatang

  • Saat ini sudah dioperasikan bersama mitra awal seperti Ramp, Intercom, dan fal
  • Hingga sebelum GA (general availability), mereka mempertahankan loop umpan balik yang cepat melalui open build
  • Mengundang tim dan penggemar yang tertarik untuk menghubungi mereka

Bacaan terkait

4 komentar

 
roxie 2025-08-15

Saya membacanya sambil berpikir, "Perusahaan ini menghasilkan uang dengan cara apa ya?", dan ternyata mereka memang berencana menawarkan pyx secara berbayar.
 
ndrgrd 2025-08-14

Pernyataan bahwa semua tantangan packaging Python sudah terselesaikan terdengar lucu.
Bukannya terselesaikan, ini cuma dibereskan seadanya supaya sekadar tetap jalan, kan? haha

Python adalah bahasa arus utama yang digunakan di seluruh dunia, jadi memang benar lingkungannya sangat berantakan.
Di komentar Hacker News orang-orang khawatir karena yang turun tangan adalah 'perusahaan', tetapi mereka tidak memikirkan bahwa situasinya jadi seperti ini justru karena tidak ada seorang pun yang peduli sampai perusahaan turun tangan.
 
aqqnucs 2025-08-14

FYI: mengutip apa yang dikatakan seseorang di komentar Hacker News
 
GN⁺ 2025-08-14
Komentar Hacker News

  • Mungkin artikel blog ini lebih berguna untuk dibagikan https://astral.sh/blog/introducing-pyx

    • Meskipun tautan ini penjelasannya lebih jelas, saya masih belum benar-benar paham masalah yang mereka coba selesaikan dan bagaimana tepatnya solusi itu bekerja

  • Saya rasa semua masalah packaging Python sebenarnya sudah terselesaikan. Pelajaran yang saya ambil di sini adalah tidak ada satu solusi yang pas untuk semua masalah. Memperbanyak keterkaitan dengan perusahaan yang didanai VC atau bergantung pada infrastruktur mereka selalu merupakan risiko besar bagi komunitas FOSS

    • Saya mulai karena disuruh pakai pip. Tapi lambat dan sering bermasalah. Jadi saya pindah ke virtualenv, tapi itu hanya menyelesaikan sebagian masalah. Setelah itu saya pakai conda, kadang berjalan baik, tapi profil shell saya jadi berantakan dan versi paket sering kusut. Lalu saya direkomendasikan pipenv, yang awalnya bagus, tapi pengembangannya terbengkalai dan setelah orang-orangnya berganti, versi terbarunya sering rusak. Setelah itu saya direkomendasikan poetry, tapi terlalu lambat sehingga tak bisa dipakai. Jadi saya kembali ke pip dan venv bawaan, tapi saya kembali menemui masalah lama dan fiturnya juga lebih kurang. Lalu saya pindah ke uv, dan ini setidaknya benar-benar bekerja. Tapi dependensi yang saya butuhkan punya cara build dan packaging yang berbeda menurut sistem operasi dan GPU, jadi rekan kerja saya bahkan tidak bisa memasang proyek ini di laptop mereka. Syukurlah sekali masalah packaging Python semuanya sudah "terselesaikan"

    • Klaim bahwa "semua masalah packaging Python sudah terselesaikan" terus terang terdengar seperti omong tanpa tahu atau hasil dari ketidaktahuan. Python masih belum punya cara yang andal untuk menangani dependensi native di berbagai platform. pip dan setuptools seharusnya tidak menjadi akhir dari ekosistem ini

    • Saya setuju dengan kekhawatiran itu, tapi sejak memakai uv saya menghemat sangat banyak waktu, jadi saya akan tetap memakainya sampai dampak buruk modal VC benar-benar merusaknya. Semoga pada saat itu komunitas bisa berkumpul ke satu arah

    • Selama 3 jam terakhir saya bergulat dengan python dan debian, dan kemarahan saya terhadap ekosistem Python memuncak. Sama sekali belum terselesaikan. Di Debian, yang disarankan hanya memakai venv, tapi paket yang dipasang di venv sering tidak bisa ditemukan alat seperti cmake. Ada juga paket apt-get, beberapa alat hanya bisa menemukan itu, yang lain malah tidak bisa. Nama paketnya juga tidak konsisten. Konsol saya merekomendasikan pipx, tapi pengalaman pakainya mirip saja. Selain itu, sisa-sisa lama python 2 vs 3 masih ada, sehingga pencarian paket sering gagal hanya karena ada atau tidaknya nomor versi. Saya bahkan tidak tahu apa itu c++headerparser, tapi pada akhirnya saya makin yakin bahwa tindakan yang benar adalah mengeluarkan Python dari build tree dan membiarkannya terkubur dalam sejarah

    • Baru datang ya? Saya sarankan coba minum Kool Aid ini. Tidak usah perhatikan logo "MongoDB" yang menempel di gelasnya. Itu barang lama

  • Saya sudah terlalu sering terluka karena percaya pada produk open source. Janji seperti ini sudah tak terhitung banyaknya. Pada akhirnya akan diakuisisi, lalu dokumentasi, issue, dan PR yang menumpuk selama bertahun-tahun dibersihkan nyaris tanpa peringatan. Setelah itu perusahaan barunya merilis produk komersial, tapi kadang fitur inti yang saya pakai justru hilang

    • Meski saya paham kekhawatiran itu, saya ingin menekankan bahwa pyx adalah produk yang secara strategis dipisahkan dari tool Astral yang sudah ada. Dalam pengumuman resminya juga tertulis, "pyx adalah perwujudan strategi Astral, dan tool Astral akan tetap gratis, open source, dan berlisensi sangat permisif untuk selamanya." Tujuan kami adalah mengurangi kekhawatiran dengan membuat produk terpisah yang berkelanjutan secara komersial, alih-alih memonetisasi tool open source

    • Kekhawatiran itu sepenuhnya masuk akal. Meski begitu, saya rasa reputasi dan rekam jejak Astral benar-benar luar biasa. Saya malah terkejut melihat respons yang begitu hati-hati di HN. Saya sudah lebih dari 10 tahun mengembangkan dengan Python, dan kalau Astral mengerjakan sesuatu saya selalu jadi antusias

    • Kalau memang fiturnya benar-benar bernilai, saya rasa itu akan sudah digabungkan ke pip

  • Saya sangat relate dengan keluhan bahwa memasang PyTorch, CUDA, atau hal seperti FlashAttention dan DeepSpeed itu sulit. Di Windows (dan WSL), ada juga masalah bahwa beberapa paket menuntut compiler dari versi Visual Studio yang sangat lama, sehingga kita harus repot mencari sendiri jalur unduhnya. Saya menunggu pengalaman pengembangan yang lebih baik

    • Sebenarnya WSL hampir sama dengan Linux, jadi saya rasa versi compiler Visual Studio tidak terlalu penting. Binary WSL semuanya dibangun dengan toolchain Linux. Bahkan di Windows pun, libc sudah sangat stabil sejak Win10. Binary yang dibangun dengan VC++ 2015 ke atas tetap menjaga kompatibilitas C-ABI satu sama lain. Pengecualiannya hanya jika bahasa atau fitur tertentu tidak didukung compiler lama, atau jika Anda mencoba langsung melewatkan objek C++ melintasi ABI. Kasus seperti itu jarang

    • Karena pengalaman seperti ini, saya pernah benar-benar meninggalkan Ruby gara-gara Rails. Waktu lihat video Ruby, semua orang tampak senang ngoding dan saya iri, tapi di lingkungan saya, untuk menyiapkan lingkungan pengembangan saya harus memakai droplet DigitalOcean, dan sering gagal karena error saat kompilasi untuk Rails. Sekitar tahun 2012 saya ingin ikut gelombang Rails, tapi proses konfigurasi/instalnya selalu seperti mimpi buruk. Jadi saya pindah ke Python, dan pada awalnya baik-baik saja, tapi belakangan kalau menyangkut AI atau CUDA, rasanya malah lebih masuk akal sekadar mengikuti shell script orang lain karena install hell-nya begitu parah

    • Saya rasa inilah arah yang seharusnya dituju packaging Python untuk workflow yang berpusat pada GPU. Ada dua hal yang khususnya saya nantikan. Pertama, adanya indeks tervalidasi kompatibilitas per akselerator (misalnya CUDA/ROCm/CPU masing-masing), sehingga perdebatan matriks torch/cu* hilang. Kedua, metadata bisa di-query oleh klien agar instalasi dapat diparalelkan. Jika pyx bisa mengurangi "loop trial-and-error pip" di lingkungan ML, sekaligus menyediakan build yang ditargetkan ke hardware serta hash yang dapat diprediksi, waktu yang dibutuhkan untuk menyiapkan lingkungan akan berkurang drastis. Selain itu, model yang membiarkan tool-nya tetap open source dan menghasilkan pendapatan dari layanan hosting juga positif untuk membangun kepercayaan. Saya penasaran apakah pyx akan mendukung pemeriksaan supply chain seperti graph dependensi, reverse dependency (apa yang rusak jika X→Y?), dan bukti SBOM/tanda tangan

    • Dulu, sistem operasi itu dianggap wajar jika menyertakan compiler bawaan

    • Alasan utama saya dulu memakai anaconda juga karena lingkungan seperti ini

  • Ada candaan bahwa "sebentar lagi akan ada 14 standar packaging Python yang saling bersaing". Sebenarnya 14 itu bercanda, karena jumlahnya sudah jauh lebih banyak sejak lama

    • Memang ada sangat banyak standar dalam packaging Python, tapi menurut saya sebagian besar yang lahir dalam sekitar 10 tahun terakhir sebenarnya tidak saling bersaing. Lebih tepatnya, itu adalah "hasil akumulasi bertahap dari fitur-fitur yang dianggap berguna". Itu karena standardisasi packaging Python berlangsung lewat proses yang sehat dan berbasis konsensus, bukan otoriter. Kalau prosesnya otoriter, saya rasa Python tidak akan menikmati kesuksesan seperti sekarang (sebagai catatan, saya punya pengalaman mengusulkan setidaknya 5 PEP)

  • Saya rasa packaging Python adalah bagian dari Python yang paling bertentangan dengan Zen Python

  • September tahun lalu, Charlie mengungkapkan di Mastodon bahwa dia sedang memikirkan model bisnis ini https://hachyderm.io/@charliermarsh/113103564055291456

  • Saya penasaran apa tepatnya yang dimaksud dengan registry yang GPU-aware. Apakah artinya uv bisa memeriksa spesifikasi GPU saya lalu otomatis mengambil set paket yang cocok dari Pyx? Jika ini adalah registry privat berbayar untuk pelanggan perusahaan, apakah perusahaan semacam itu juga bisa menyediakannya ke luar sebagai instance publik? Maksud saya, jika saya adalah vendor, apakah saya bisa menjalankan registry Pyx berbayar untuk paket-paket saya sendiri dan memakainya sebagai entry point bagi pelanggan saya?

    • uv sebenarnya sudah mendukung bentuk dasar dari ide ini. Misalnya, jika Anda menjalankan uv pip install --torch-backend=auto torch, dari indeks PyTorch ia akan otomatis memasang versi PyTorch yang cocok dengan GPU Anda. pyx adalah model yang mengembangkan ini lebih jauh. Bukan hanya PyTorch, tapi ada indeks yang dikurasi untuk tiap akselerator hardware, dan di indeks itu tersedia artefak build untuk berbagai paket, versi, versi Python, versi PyTorch, dan seterusnya, semuanya dengan metadata yang konsisten. Jadi dengan pyx, Anda bisa lebih mudah mendapatkan build yang cocok dari sisi kompatibilitas/kecepatan, dan klien uv juga bisa otomatis menemukan indeks pyx yang sesuai untuk Anda (bagian ini pada dasarnya diimplementasikan baik Anda memakai pyx atau tidak, hanya saja dengan pyx jauh lebih kuat). Selain itu, kemampuan agar vendor bisa langsung menjalankan registry bergaya pyx yang disesuaikan untuk paket mereka sendiri dan memberikannya sebagai pintu masuk ke pelanggan memang belum didukung secara resmi, tapi jika ada minat yang konkret mereka terbuka untuk dihubungi dan didiskusikan

  • Saya juga sudah bilang beberapa minggu lalu, suatu saat Astral pasti akan memakai strategi monetisasi. Menurut saya inti utamanya bukan Uv, melainkan sesuatu seperti PyPI privat yang terlindungi https://news.ycombinator.com/item?id=44712558

    • Saya kurang paham inti komentar ini. Sebenarnya Charlie Marsh sudah menjelaskan hal ini langsung pada September tahun lalu — bentuk seperti registry paket privat untuk enterprise bisa menjadi contoh strategisnya (meski belum tentu persis begitu, itu dipakai untuk menunjukkan arah strateginya secara konkret). Astral sangat transparan soal model bisnisnya https://hachyderm.io/@charliermarsh/113103605702842937

    • Kata "monetisasi" mungkin terdengar negatif, tapi mereka benar-benar telah membuat tool yang luar biasa, jadi dari sudut pandang perusahaan yang ingin mereka menyelesaikan jauh lebih banyak masalah, tentu mereka bersedia membayar

    • Saya belum mengadopsi uv, dan masih mengamati langkah mereka ke depan. Belakangan saya juga harus meninjau ulang pemakaian tool Anaconda karena perubahan lisensi, dan hal yang sama terjadi pada Qt. Membayangkan harus menghadapi masalah lisensi lain lagi rasanya memberatkan