PYX: Python paketlemede bir sonraki adım

 (astral.sh)
18 puan yazan GN⁺ 2025-08-14 | 4 yorum | WhatsApp'ta paylaş
  • pyx, uv geliştirme ekibi tarafından oluşturulan Python’a özgü yerel paket kayıt defteri olup, PyPI, PyTorch ve özel kaynaklardan kurulum hızını 10 kata kadar artırır
  • Mevcut paket kayıt defteri kapsamının ötesine geçerek hız, güvenlik ve GPU farkındalığı sunar; hem dahili paketleri hem de PyPI ve PyTorch gibi açık kaynakları destekler
  • Paket popülerliği, oluşturulma zamanı ve güvenlik açığı durumu gibi ölçütlere göre filtrelenebilen özel indeks URL’leri sağlayarak güvenlik ve uyumluluğu güçlendirir
  • Python’a özel güncel standart desteği ve uv ile doğrudan entegrasyon sayesinde yapılandırma gerektirmeden kimlik doğrulama ve kullanım sağlar
  • Ekip içi yinelenen build’ler, PyTorch ve CUDA kurulum zorluğu, build kırılmaları ve kimlik doğrulama sıkıntıları gibi kurumsal ortamdaki temel sorunları sunucu-istemci entegrasyonuyla çözer
  • GPU farkındalığı ile PyTorch, vLLM, FlashAttention ve DeepSpeed gibi araçların donanıma uygun önceden derlenmiş sürümlerini tutarlı meta veriler ve en uygun yapılandırmayla sunar
  • Optimize edilmiş artifact’ler ve uv’ye özgü yerel meta veri API’si sayesinde diğer özel kayıt defterlerine kıyasla üstün performans sağlar

Astral’ın vizyonu ve arka planı

  • Astral, Python ekosistemi için yüksek performanslı geliştirme araçları üreten bir şirket olup Ruff (linter/formatter) ve uv (paket yöneticisi) ile tanınır
  • Şirketin kuruluş motivasyonu, Python dünyanın en popüler programlama dili olmasına rağmen araç desteği açısından yeterince desteklenmediğini düşünmeleriydi
  • Bugün Astral araç zinciri ayda 100 milyondan fazla kurulum alıyor ve uv günde 500 milyondan fazla isteği işleyerek hızla büyüyor
  • Hedef, Python’u en üretken programlama ekosistemi haline getirmek; bunun için istemci araçlarının ötesine geçerek bir Python bulutu kurmak istiyorlar

pyx’e giriş

  • pyx, uv’nin optimize edilmiş arka ucu olarak tasarlanmış Python’a özgü yerel paket kayıt defteridir
    • Dahili paketleri barındırabilir
    • PyPI ve PyTorch indeksleri gibi açık kaynaklar için hızlandırılmış ve yapılandırılabilir bir ön uç görevi görür
  • Başlıca özellikleri
    • Hızlı kurulum: paket kurulumu ve build optimizasyonu
      • PyPI, PyTorch ve dahili özel kaynaklardan paket kurarken optimize edilmiş artifact’ler ve uv’ye özgü yerel meta veri API’sini kullanır
      • Diğer özel kayıt defterlerine kıyasla 10 kata kadar daha hızlıdır
      Reklam
    • Gelişmiş güvenlik ve uyumluluk: bağımlılıkları ve tedarik zincirini anlayarak riski en aza indirir
      • Paket filtreleme için özel indeks URL’leri oluşturulabilir
      • Popülerlik, yayın yaşı ve güvenlik açığı durumu gibi ölçütlere göre paket erişimi kontrol edilebilir
      • Sunucu tarafında yeniden üretilebilir build’ler garanti edilir
    • Güncel standart desteği
      • Python’a özgü en yeni paketleme standartlarını ve iş akışlarını destekler
      • uv ile doğrudan entegredir; ek yapılandırma olmadan sorunsuz kimlik doğrulama ve kullanım sağlar
    • GPU farkındalığına sahip paket dağıtımı: CUDA ve PyTorch ile ilgili build ve dağıtımı basitleştirir
      • PyTorch, vLLM, FlashAttention ve DeepSpeed gibi GPU ile ilgili kütüphaneler için özelleştirilmiş önceden derlenmiş sürümler sunar
      • Donanıma göre en uygun yapılandırmayı ve tutarlı meta veriyi korur
Reklam

Çözmeyi hedeflediği sorunlar

  • PyTorch, CUDA, FlashAttention ve DeepSpeed gibi GPU ile ilgili kütüphanelerin kurulum zorluğu
  • Ekip içinde aynı paketin tekrar tekrar build edilmesinden kaynaklanan kaynak israfı
  • setuptools güncellemelerinin yol açtığı build hataları
  • Dahili kayıt defterlerinde zahmetli kimlik doğrulama süreci

Sunucu-istemci entegrasyon stratejisi

  • uv (istemci) ile pyx (sunucu) arasında dikey entegrasyon kurarak bu sorunları doğrudan çözer
  • pyx olmadan yalnızca uv veya uv olmadan yalnızca pyx kullanılabilir, ancak birlikte kullanıldığında en iyi deneyimi sunar
  • Açık kaynak araçlarla derin entegrasyon sayesinde daha önce mümkün olmayan bir geliştirme deneyimi sağlar

İş modeli

  • uv, Ruff ve ty gibi Astral araçları kalıcı olarak ücretsiz, açık kaynaklı ve permissive lisanslı kalacaktır
  • Bunun yerine pyx gibi ücretli barındırma hizmetleri sunarak “bir sonraki adım” altyapı talebini karşılayacaktır

Mevcut durum ve gelecek planları

  • Şu anda Ramp, Intercom ve fal gibi ilk iş ortaklarıyla kullanımdadır
  • GA (genel kullanıma açılma) öncesine kadar açık geliştirme ile hızlı bir geri bildirim döngüsü sürdürülecektir
  • İlgilenen ekiplerin ve kullanıcıların iletişime geçmesi isteniyor

İlgili okumalar

4 yorum

 
roxie 2025-08-15

"Bu şirket nasıl para kazanıyor acaba?" diye düşünerek okumaya devam ettim; meğer pyx'i ücretli olarak sunmayı planlıyorlarmış.
 
ndrgrd 2025-08-14

"All python packaging challenges are solved" demek gerçekten komik bir hikâye.
Çözülmüş değil, sadece bir şekilde çalışır halde kenara itilmiş gibi değil mi?

Python dünyanın her yerinde kullanılan ana akım bir dil ama ekosisteminin aşırı dağınık olduğu da bir gerçek.
Hacker News yorumlarında "kurumlar"ın devreye girmesinden endişe ediliyor ama kurumlar harekete geçene kadar kimsenin bu konuyla ilgilenmediği için durumun bu hale geldiği pek düşünülmüyor.
 
aqqnucs 2025-08-14

Bilginize: Hacker News yorumlarında birinin söylediği şey alıntılanıyor
 
GN⁺ 2025-08-14
Hacker News görüşleri

  • Muhtemelen daha faydalı bir blog yazısı paylaşılmış: https://astral.sh/blog/introducing-pyx

    • Bu bağlantı daha net bir açıklama sunsa da, çözmeye çalıştıkları sorunu ve çözümün tam olarak nasıl işlediğini hâlâ pek anlayabilmiş değilim

  • Tüm Python paketleme sorunlarının zaten çözülmüş olduğunu düşünmüyorum. Buradan çıkarılacak ders, her probleme tam uyan tek bir çözüm olmadığı. VC destekli şirketlerle bağları artırmak ya da onların altyapısına bağımlı olmak FOSS topluluğu için her zaman büyük bir risk

    • Bana pip kullanmam söylendiği için onunla başlamıştım. Ama yavaştı ve sık sık sorun çıkarıyordu. Sonra virtualenv'e geçtim, ama bu yalnızca sorunun bir kısmını çözdü. Ardından conda kullandım; bu bazen iyi çalışıyordu ama shell profilimi darmadağın etti ve paket sürümleri sık sık birbirine giriyordu. Sonra bana pipenv önerildi; başta iyiydi ama geliştirme sahipsiz kalınca ve ekip değişince son sürümlerde sık sık bozulmaya başladı. Daha sonra yine poetry önerildi, ama o kadar yavaştı ki kullanamadım. Böylece tekrar pip ve yerleşik venv'e döndüm, ama daha önce yaşadığım sorunlarla yeniden karşılaştım ve üstelik daha az özelliği vardı. Sonra uv'ye geçtim; bu en azından düzgün çalıştı. Ama ihtiyacım olan bağımlılıkların derleme ve paketleme biçimi işletim sistemine ve GPU'ya göre değiştiği için, ekip arkadaşlarım bu projeyi kendi dizüstü bilgisayarlarına bile kuramıyor. Python paketleme sorunlarının "çözüldüğünü" duymak gerçekten ne güzel

    • "Tüm Python paketleme sorunları zaten çözüldü" demek, açıkçası ya konuyu bilmeden konuşmak ya da cehalet. Python'un hâlâ farklı platformlarda yerel bağımlılıkları güvenilir biçimde ele almanın bir yolu yok. pip ve setuptools bu ekosistemin nihai noktası olmamalı

    • Endişe edilen kısma katılıyorum ama uv kullandıktan sonra o kadar çok zaman kazandım ki, VC sermayesinin kötü yanları bunu tamamen mahvedene kadar kullanmaya devam edeceğim. O zamana kadar umarım topluluk ortak bir yönde birleşebilir

    • Son 3 saattir python ile debian'ı uzlaştırmaya çalışırken Python ekosistemine karşı öfkem tavan yaptı. Hiçbir şey çözülmüş değil. Debian'da yalnızca venv kullanman öneriliyor ama venv içine kurulan paketleri cmake türü araçlar kolayca bulamıyor. apt-get paketleri de var; bazı araçlar yalnızca onları buluyor, bazıları ise onları bile bulamıyor. Paket isimleri de tutarlı değil. Konsolum bana pipx önerdi ama deneyim benzerdi. Bir de eski python 2 vs 3 kalıntıları hâlâ duruyor; sürüm numarasının isimde olup olmaması yüzünden paket keşfi sık sık başarısız oluyor. c++headerparser denen şey her neyse, sonuçta Python'u derleme ağacından çıkarıp tarihe gömmek gerektiğine daha da ikna oldum

    • Buraya yeni mi geldiniz? Size biraz Kool Aid ikram edelim. Bardaktaki "MongoDB" logosuna aldırmayın. O eski bir şey

  • Açık kaynak ürünlere defalarca güvenip hayal kırıklığı yaşadım. Bu tür vaatleri sayısız kez duydum. Bir gün birileri gelip satın alıyor, yıllar içinde biriken dokümantasyon, issue'lar ve PR'lar neredeyse haber bile verilmeden temizleniyor. Sonra yeni şirket ticari bir ürün çıkarıyor ama benim kullandığım temel özelliklerden bazıları ortada olmuyor

    • Bu kaygıyı anlıyorum ama şunu vurgulamak isterim: pyx, Astral'ın mevcut araçlarından stratejik olarak ayrılmış bir ürün. Resmî duyuruda da, "pyx, Astral'ın stratejisinin bir gerçekleşmesidir ve Astral'ın araçları sonsuza dek ücretsiz, açık kaynak ve çok müsamahalı bir lisansla kalacaktır" deniyor. Hedefimiz, açık kaynak araçlardan doğrudan para kazanmak yerine, ayrı ve ticari olarak sürdürülebilir bir ürün geliştirip bu kaygıları azaltmak

    • Bu kaygı tamamen anlaşılır. Yine de Astral'ın itibarı ve bugüne kadarki işleri gerçekten etkileyici. HN'de bu kadar temkinli bir tepki görünce şaşırdım. 10 yılı aşkın süredir Python geliştiriyorum ve Astral ne yaparsa yapsın ilgimi çekiyor

    • Gerçekten değerli bir özellik olsaydı pip'e entegre edilirdi diye düşünüyorum

  • PyTorch, CUDA ya da FlashAttention, DeepSpeed gibi şeyleri kurmanın zor olduğu tespitine tamamen katılıyorum. Windows'ta (ve WSL'de) bazı paketlerin çok eski bir Visual Studio sürümünün derleyicisini istemesi, insanı o sürümü elle indirip yolunu bulmak zorunda bıraktığı için ayrıca uğraştırıyor. Daha iyi bir geliştirici deneyimi bekliyorum

    • Aslında WSL neredeyse Linux ile aynı olduğu için, Visual Studio derleyici sürümünün çok da önemli olmadığını düşünüyorum. WSL ikilileri tamamen Linux toolchain'i ile derleniyor. Windows'ta da libc, Win10'dan beri oldukça stabil. VC++ 2015 ve sonrası ile derlenmiş ikili dosyalar arasında C-ABI uyumluluğu korunuyor. İstisna olarak yalnızca bazı dillerin ya da özelliklerin eski derleyiciler tarafından desteklenmemesi veya C++ nesnelerini doğrudan ABI sınırları arasında geçirmeye çalışmak gibi durumlarda eski bir derleyici gerekebilir. Bunlar da nadir vakalar

    • Bu tür hikâyeler yüzünden zamanında Rails sayesinde Ruby'den tamamen uzaklaştım. Ruby videolarında herkes keyifle geliştirme yapıyor gibi görünüyordu ve imreniyordum, ama benim ortamımda geliştirme ortamı kurmak için DigitalOcean droplet kullanmak zorunda kalıyordum ve Rails için derleme sırasında sık sık hata alıyordum. 2012 civarında Rails dalgasına katılmak istedim ama kurulum/yapılandırma süreci hep kâbus gibiydi. Sonra Python'a geçtim; ilk başlarda iyiydi ama bugünlerde konu yapay zeka ya da CUDA olduğunda, kurulum cehenneminden dolayı çoğu zaman başkasının shell script'ini takip etmek daha mantıklı geliyor

    • GPU merkezli iş akışlarında Python paketlemesinin bu yöne gitmesi gerektiğini düşünüyorum. Özellikle heyecan verici iki nokta var. Birincisi, hızlandırıcıya özel (ör. CUDA/ROCm/CPU ayrı ayrı) uyumluluğu doğrulanmış indekslerin sunulması; böylece torch/cu* matrisi tartışması ortadan kalkar. İkincisi, istemcinin metadata'yı sorgulayıp kurulumu paralelleştirebilmesi. Eğer pyx, ML ortamlarında yaşanan o pip deneme-yanılma döngüsünü azaltır ve ayrıca donanım hedefli derlemeler ile öngörülebilir hash'ler sağlarsa, ortam kurulumuna harcanan zaman ciddi biçimde azalır. Aracın kendisini açık kaynak bırakıp gelirini barındırma hizmetinden elde etme modeli de güven inşa etmek açısından olumlu. pyx'in bağımlılık grafiği, ters bağımlılıklar (X→Y olursa ne bozulur?), SBOM/imza kanıtı gibi tedarik zinciri kontrollerini de destekleyip desteklemeyeceğini merak ediyorum

    • Bir zamanlar işletim sistemi denince derleyicinin de içinde gelmesi normaldi

    • Vaktiyle anaconda kullanmamın belirleyici nedeni de tam olarak buydu

  • Yakında birbiriyle yarışan 14 ayrı Python paketleme standardı olacak diye şaka yapılmıştı. Aslında 14 kısmı şaka; sayısı uzun zamandır onu da geçti

    • Python paketlemesinde gerçekten çok sayıda standart var ama son 10 küsur yılda ortaya çıkanların çoğunun birbiriyle rekabet ettiğini düşünmüyorum. Daha çok, "işe yarar görülen işlevlerin zaman içinde kademeli olarak birikmesi" gibi. Bunun nedeni, Python'daki paketleme standardizasyonunun otoriter değil, uzlaşma temelli işleyen sağlıklı bir süreç olması. Otoriter olsaydı Python bugün sahip olduğu başarıya ulaşamazdı diye düşünüyorum (bu arada en az 5 PEP önerisi deneyimim var)

  • Python paketlemesinin, Python içindeki en anti-Zen kısım olduğunu düşünüyorum

  • Geçen yıl eylülde Charlie, Mastodon'da bu iş modelini tasarlamakta olduğunu söylemişti: https://hachyderm.io/@charliermarsh/113103564055291456

  • GPU-aware bir registry'nin somut olarak ne anlama geldiğini merak ediyorum. Yani uv benim GPU özelliklerimi kontrol edip ona uygun paket setini Pyx'ten otomatik olarak mı çekecek? Bu, kurumsal müşterilere yönelik özel ve ücretli bir registry ise, şirketlerin böyle bir registry'yi herkese açık bir instance olarak dışarıya sunabilmesi de mümkün olacak mı? Yani ben bir vendor olsam, kendi paketlerim için ücretli bir Pyx registry işletip bunu müşterilerime giriş noktası olarak sunabilir miyim diye merak ediyorum

    • uv zaten bu fikrin temel bir versiyonunu destekliyor. Örneğin uv pip install --torch-backend=auto torch derseniz, PyTorch indeksinden GPU'nuza uygun PyTorch sürümünü otomatik olarak kuruyor. pyx bunun daha gelişmiş hâli. Yalnızca PyTorch için değil, her donanım hızlandırıcısı için özenle hazırlanmış indekslere sahip ve bu indekslerde çeşitli paketler, sürümler, Python sürümleri, PyTorch sürümleri vb. için derlenmiş çıktılar tutarlı metadata ile hazır bulunuyor. Yani pyx kullanırsanız, uyumluluk ve hız açısından uygun derlemeleri kolayca alabilirsiniz; uv istemcisi de uygun pyx indeksini sizin yerinize otomatik olarak bulabilir (bu kısım pyx kullansanız da kullanmasanız da temel düzeyde uygulanmış durumda, ama pyx ile çok daha güçlü oluyor). Ayrıca bir vendor'ın kendi paketlerine uygun Pyx tarzı bir registry'yi doğrudan işletip bunu müşterilerine giriş noktası olarak sunması henüz resmî olarak desteklenmiyor; ama somut ilgi varsa iletişime geçilip konuşulabilir

  • Bunu birkaç hafta önce de söylemiştim: Astral bir gün mutlaka para kazanma stratejisini uygulayacak. Bence işin merkezinde Uv değil, korumalı bir özel PyPI benzeri bir şey olacak: https://news.ycombinator.com/item?id=44712558

    • Bu yorumun tam olarak neyi hedeflediğini anlamıyorum. Aslında Charlie Marsh bunu geçen yıl eylülde bizzat açıklamıştı: kurumsal kullanıma yönelik özel paket registry'si gibi bir şey stratejik bir örnek olabilir demişti (ille de tam olarak bunu yapacağız demek için değil, stratejinin nasıl bir yöne gidebileceğini somutlaştırmak için). Astral iş modeli konusunda oldukça şeffaf: https://hachyderm.io/@charliermarsh/113103605702842937

    • "Para kazanma" kulağa olumsuz gelebilir ama gerçekten olağanüstü araçlar yaptılar; daha fazla sorunun çözülmesini isteyen şirketler de bunun için memnuniyetle ödeme yapacaktır

    • uv'yi henüz benimsemedim, şimdilik nasıl bir yola gireceklerini izliyorum. Yakın zamanda Anaconda araçlarını da lisans değişikliği nedeniyle yeniden değerlendirmek zorunda kaldık, Qt için de aynı şey geçerliydi. Bir başka lisans sorunuyla daha uğraşma ihtimali bile yorucu geliyor