Rye ve uv: Ağustos, Python paketleme için hasat sezonu

• Rye’nin yönetimi Şubat 2024’te Astral’a geçtikten sonra, temel resolver ve installer olan uv hızla gelişerek Python paketleme araçlarını birleştirme adayı olarak öne çıktı
• En yeni uv; pyproject.toml düzenleme, workspace desteği, yerel paket referansları, script kurulumu ve Python kurulum yönetimini de kapsayarak Rye’ın üstlendiği alanları bünyesine katıyor
• AI ve ML yatırımlarıyla Python’a yeni kullanıcılar artsa da paketleme aracı seçeneklerinin çokluğu ve uyumlulukların farklılaşması nedeniyle geliştirici deneyimi hâlâ tutarlı değil
• Paketleme ekosisteminde herkesin kullandığı baskın bir araç olmalı ki yatırım ve dokümantasyon tek bir stack etrafında toplansın; Rye’ın uv merkezli geçiş için bir migrasyon yolu olması güçlü bir olasılık
• Astral’ın VC yatırımı, PSF ve Python çekirdek projesinin dikkate alması gereken bir risk; ancak uv, en kötü senaryoda bile fork edilip bakımı sürdürülebilecek bir kod olarak değerlendiriliyor

---

Rye’dan uv’ye işlevlerin toplandığı akış

• Şubat 2024’te Rye’ın yönetimi Astral’a geçti ve sonraki birkaç ay içinde Astral, Python paketleme aracını hızla geliştirdi
• Rye kullanıcıları, temel resolver ve installer olan uv’nin daha iyi ve daha hızlı hâle geldiğini hissedebildi
• En yeni uv, eskiden Rye gerektiren özellikleri doğrudan sunmaya başladı
  • pyproject.toml dosyalarını düzenleme
  • workspace desteği
  • yerel paket referansları
  • script kurulumu
  • Python kurulum yönetimi
• Şu anda Rye kullananların uv’ye göz atıp Astral’a geri bildirim vermesi gerekiyor

Python paketleme araçlarının tek noktada toplanması neden gerekli?

• EuroPython Prague sunumu, Python paketlemenin mevcut durumuna ve Rye geliştirilirken çıkarılan derslere odaklanıyor
• Paketleme aracının hedefi, kendi alanında baskın araç olmaktır
  • Herkesin kullandığı araç, en iyi araç olmalı
  • Çünkü Python’la ilk kez tanışan kişilerin programlama yolculuğuna başlarken karşılaştığı araç budur
• Son 2 yılda Python, AI ve ML’ye yönelik yatırım ve ilginin etkisiyle yeni geliştiriciler için çok sıcak ve popüler bir platform hâline geldi
• Yeni kullanıcıların Python’u eski ve araçları kötü bir dil olarak değil, mükemmel bir geliştirici deneyimine sahip bir dil olarak hatırlaması önemli
• Ancak mevcut Python paketleme dünyasında çok fazla seçenek var, araçlar arası uyumluluk tam değil ve farklı noktalardaki tutarsızlıklar deneyimi sarsıyor
  • Bazı kullanıcılar bir aracı takip ederken duvara toslayıp tüm stack’i conda’ya taşıdıktan sonra geri dönmek zorunda kalabiliyor

uv’nin baskın araç olma ihtimali

• Bir aracın baskın konuma sahip olması, yatırımların büyük bölümünün tek bir stack’te toplanması anlamına gelir
• Rye ve çevresindeki çeşitli araçlar için, baskın bir araç yerleştiğinde artık bağımsız olarak var olmak zorunda kalmamaları tercih edilir
• Şu anda uv, bu rolü üstlenme olasılığı en yüksek araç olarak görülüyor
  • Henüz tüm kullanım senaryolarını karşılamıyor
  • Ancak bu noktaya hızla ulaşacak gibi görünüyor
• Topluluğun artık uv etrafında toplanmaya başlaması gereken zamandayız
• Bu, aracın sonsuza kadar tek araç olacağı anlamına gelmiyor
  • Araçlar ortaya çıkıp kaybolabilir
  • Gelecekte başka araçlar da çıkabilir

Rye’ın emekliye ayrılması ve Python proje rehberliğinin değişimi

• Beklenen son Rye sürümü, Rye’a özgü özellikleri emekliye ayırıp kullanıcıları uv’ye migrate eden ve büyük ölçüde uv’nin takma adı gibi davranan bir biçimde olacak
• Sadece Rye’ı emekliye ayırmak yeterli değil
  • Bugün Python’da çeşitli paket yönetimi çözümleri kullanılıyor
  • Topluluk daha az sayıda aracı önermeli
• Rye ve uv, altlarındaki ekosistemin uzun gelişimi üzerine inşa edildi
  • setup.pyden eggs’e, oradan wheels’a geçiş akışı
  • Metadata standardının yokluğundan standartların bulunduğu duruma geçiş akışı
  • Birleşik build sistemlerinden ayrık build sistemlerine geçiş akışı
  • Yeniden dağıtılabilir ve indirilebilir Python binary’lerini mümkün kılan çalışmalar
  • İlgili Rust crates ve Python kütüphane ekosistemi
• Topluluğun bir gün bazı araçları artık önermediğini söylemeye hazır olması gerekiyor
  • Eskiden yeni geliştirici rehberlerinde ez_setup.py ve easy_install öneriliyordu
  • Daha sonra rehberlerden ez_setup.py kaldırılıp yerine pip getirildi
  • Bazı projeler pip-tools, poetry, PDM önerdi
  • Bugün birçok proje, farklı araçlar yüzünden aynı anda 5 farklı kurulum yönergesi gösterebiliyor
• Önemli Python projelerinin maintainers’ları uv’yi bizzat deneyip kullanıcılara uv’yi önermenin mümkün olup olmadığını değerlendirmeli
• Astral’dan Charlie’nin yazdığı uv’nin şu anda neler yapabildiğine dair yazı, uv’nin mevcut başarısını gösteriyor

Astral’ın VC yatırımı ve topluluk riski

• uv’yi geliştiren Astral’ın VC yatırımı almış bir şirket olması, kaçınılmaz bir tartışma konusu
• Topluluk açısından, birinin büyük miktarda para yatırması yeni zorluklar yaratabilir
• PSF ve Python çekirdek projesi bu noktayı dikkate almalı
• uv’nin koduna ve çalışma biçimine bakıldığında, en kötü gelecekte bile fork edilebilir ve bakımı sürdürülebilir bir hedef gibi görünüyor
• Astral kapansa ya da lisanslama açısından çok şüpheli bir şey yapsa bile, topluluk uv var olmadan önceki durumuna kıyasla daha iyi bir konumda olabilir

[GN⁺]

Hacker News yorumları

• uv’nin en son sürümü dün de tartışılmıştı: https://news.ycombinator.com/item?id=41302475
  Bağlantısı verilen yazı, Rye’ın yazarının o sürümü görüp yazdığı görüş yazısı

• uv ile ilgilenenler için, Home Assistant sürüm süreci pip yerine uv kullanınca büyük ölçüde hızlandı
  Sürüm için gereken süre yaklaşık 2,5 saatten yaklaşık 20 dakikaya düştü; ayrıntılar https://developers.home-assistant.io/blog/2024/04/03/build-i... adresinde. Bu arada ben sadece bir HA kullanıcısıyım

  • Derlemeli bir dil bile değilken pip’in imaj oluşturmasının 1 saatten fazla sürmesini anlayamıyorum
    Python’u hafif kullanan biri olarak tam olarak ne yaptığını bilmiyorum ama bu kadar uzun sürmesi saçma derecede yavaş geliyor

• Python paketlemede sorunlar olduğunu biliyorum ama şahsen şimdiye kadar sadece plain pip ile epey yol aldım
  En büyük değişiklik, eskiden virtualenv kullanırken yerleşik venv modülüne geçmem olmuştu. Bağımlılık yönetimini gerçekten ciddiye alacak olsam, muhtemelen FAANG tarzı bir monorepo kurup paket yöneticisiyle ilgili uğraşların çoğundan kaçınırdım

  • Monorepo’yu bizzat denemenizi gerçekten tavsiye ederim
    Üretim ortamında bir Python monorepo yönetiyorum ve bağımlılık yönetimi cehennem gibi. Poetry’nin bazı yeni özelliklerini uygulamaya çalışıyorum ama büyük monorepo’ların etrafındaki ekosistemin durumu korkunç
  • Bu konu üzerinde daha derin düşünmek gerekiyor
    Hedef “bana yetiyor” olmamalı; 2 Python geliştiricili ekiplerden yüzlerce hatta binlerce kişilik organizasyonlara kadar ölçeklenebilen paket ve sanal ortam için standart araçlara ihtiyaç var. Aksi halde ekosistem parçalanır, hatalar ve zor dokümantasyon artar, dilin etkili biçimde gelişmeye devam etmesi zorlaşır
  • Python sürümünü dert etmiyorsanız bana göre de pip + venv yeterli
    Ama bir projenin hangi Python sürümünü hedeflediğini tanımlamanın bir yolu yok. Paket geliştiriyorsanız muhtemelen birden fazla sürümde test etmeniz gerekir; kurulabilir bir dağıtım paketi değil de birkaç geliştiricinin paylaştığı bir kod demeti ise, makine öğrenimi modeli çalıştırma, bulut işlevi dağıtma ya da rapor üretme gibi işler için genelde tek bir Python sürümünü tam olarak hedeflemek istersiniz
    Ayrıca monorepo yaklaşımının numpy ve pandas’ı depoya kopyalamak anlamına mı geldiğini de merak ediyorum
  • Benim deneyimim de tamamen aynı: pip bana yetiyor

• Başta yeni aracın Python’daki “paketleme” sorununu çözeceğini ummuştum ama biraz daha okuyunca bunun, benim yazdığım Python uygulamalarını paketleme sorunundan çok paket yönetimi ile ilgili olduğunu gördüm
  Şahsen Python paket yönetiminde büyük bir sorun yaşamadım; ekosistemde eksikler var ama örneğin namespace olmaması gibi şeyler dışında pip genel olarak iyi çalışıyor
  Asıl can sıkıcı olan, Python uygulamalarını kolayca çalıştırılabilir dosyalara sarıp bir yerlere dağıtamamak. Üretim ortamında sık sık git clone ve virtualenv oluşturulduğunu görüyorum; bu, hedef sunucuda gerekenden fazla bağlantı ihtiyacı doğuruyor ve geliştirme bağımlılıkları işletim sistemi üzerinde kalıyor. Güvenlik açısından bu çok kötü bir fikir; bu sorun çözülene kadar son kullanıcıya ya da üretim dağıtımına yönelik işler için başka dilleri tercih ederim

  • Bu yanlış değil ama açarsak özü, başkalarının uygulamayı kolayca çalıştırabilmesini sağlama ihtiyacı
    Bunun için uygulamanın kullanıcıya ulaştırılması, orada Python’un bulunması ve bu sürecin kullanıcıya görünmez olması gerekir. Rye’ı yaparken ve uv için de aynı şekilde, sistemi bozmadan Python kurulumunu desteklemeye çalışmamızın nedenlerinden biri buydu
    Bunun daha gelişmiş hali, uv’yi de dahil ederek tüm süreci otomatikleştirmek. İsterseniz bugün bile curl to bash kurulum programıyla uv/Rye’ı ve uygulamayı uygulamaya özel geçici bir konuma kurabilir, kullanıcı sistemini asla bozmayan bir yapı elde edebilirsiniz
    Bir gün bu sürecin tamamen şeffaf olması, ağ erişimi gerektirmemesi ve Windows için .msi gibi seçenekler de sunması güzel olurdu. Ama bunun ön koşulu, uv gibi bir aracın önceden derlenmiş Python’u ve gereken tüm bağımlılıkları kullanıcı platformuna uygun yerlere istediği gibi yerleştirebilmesi
    uv’nin bir gün sunabileceği son bonus, tamamen paketlenmiş bir çıktı olur ve bu harika olur. O noktaya gelmeden önce bile Python ile yazılmış komut satırı araçlarını kullanıcılara ulaştırma deneyimi artık korkunç olmaktan çıkabilir. uvx kullanabilir ya da isterseniz uv’nin kendisini tamamen gizleyebilirsiniz
  • Neyi nereye kurmaya çalıştığınıza bağlı ama makul bir dağıtım hedefi için genelde o hedefe yönelik kurulabilir ikili dosya üreten araçlar vardır
    Örneğin işletim sistemine özel kurulum paketleri oluşturan araçlar var; Android, iOS ya da tarayıcı gibi daha sıra dışı hedeflere dağıtım için de araçlar çıkmış durumda. Elbette belirli bir paketin belirli bir hedefte çalışmaması mümkün, ama standart bir arayüz olduğu için kod bir yerde çalışabiliyorsa, o hedefe yönelik araç da çalışan bir çıktı üretebilmelidir

• npm’in girişim sermayesi temelli rug pull’u, Microsoft tarafından satın alınması ve OpenAI’nin hukuki olarak kâr amacı gütmeyen statüsünün bile girişim sermayesi rotasına bağlı liderler için güçsüz bir pazarlama olduğunu göstermesinden sonra, çekirdek yoldaki dil altyapısını bu tür yapılara bırakmak istemiyorum
  Buna katkı veren bireyler ayrı ayrı harika ve çoğu zaman olağanüstü olabilir, ama kurumsal düzeydeki parasal çıkarlar en başından beri kirlenmiş durumda. 1~4 yıl geçince önemli olan şey kurum oluyor. Tam bir “ya kahraman olarak ölürsün ya da yeterince uzun yaşayıp kötüye dönüşürsün” durumu
  Bu yüzden hızlı linter’lar, tip denetimi, kod tarama, PR yardımcı araçları sorun değil ve her zaman değiştirilebilir. Ama kurulum akışı ve paket deposu öyle değil
  pip ve conda’nın durumunu düşününce üzücü ama bence gerçeklik bu

  • Python’da bu kavga zaten kaybedildi
    Bence Microsoft Python’un sahibi, sadece bunu açıkça göstermiyor
    Birkaç yıl önce kubectl için Python binding’i yapmak istemiştim ve bunun çapraz platform çalışması için CGo’nun tüm platformlarda Python’la aynı derleyiciyi kullanması gerektiğini öğrendim. Ama Windows’ta CGO MINGW kullanıyor, Python ise MSVC kullanıyor. O zamanlar var olan Python geliştirici mailing list’inde “açık kaynak” bir projenin neden özel mülkiyetli bir derleyici kullandığını sordum; aldığım yanıt, MSVC’nin tarihsel bir tercih olduğu ve artık değiştirilemeyeceği yönündeydi. Gerekçe olarak Microsoft’un Python Foundation’a CI ve build çalıştırmak için ücretsiz altyapı sağladığı ve Python interpreter üzerinde çalışan geliştiriciler de sağladığı anlatıldı. Yani Microsoft çalışanları, Microsoft’tan maaş alarak Python interpreter üzerinde çalışıyor ve toolchain’den Microsoft araçlarını çıkarmamaları söyleniyor demekti
    Her yıl durum daha da kötüleşti. Benzer projelerde olduğu gibi, başarı pek de yetenekli olmayan insanların güç kazanması için zemin hazırladı ve Python Foundation ile PyPA gibi çevre projeler, faydalı kod katkısı yaptıkları için değil davranış kuralları sayfaları yazarak konuma gelen insanlarla dolmaya başladı. Bu davranış kuralları ve mevki kontrolü etrafındaki bitmek bilmeyen çekişmeler sonunda eski katkıcıların ayrılmasına ya da uzaklaştırılmasına yol açtı; son dönemde Tim sort’u yapan Tim’in bile yasaklanması buna dahil
    Microsoft, el attığı her projede yaptığı genel ajandayı itmeye devam ediyor. Yani reklam için bir sürü işe yaramaz özellik eklemek, projeyi her yöne savurmak ve özellikle de onu mümkün olduğunca modaları takip eder hale getirmek. Bu yüzden Python, tamamen farklı bir tip sistemine sahip bir dil olmasına rağmen olabildiğince makine öğrenmesi tarzı tiplerle dolduruluyor; yerel kütüphaneleri dinamik olarak bağlamak için yarı yarıya kullanılan bir dil olmasına rağmen önceden derleme ve JIT’e takılıyor. Esasen onu süslü parantezsiz bir C#’a dönüştürüyorlar
    Microsoft, Python sahipliğini açıkça ilan ederse birçok insanın teknolojiden uzaklaşacağını bilecek kadar zeki olduğu için bunu yüksek sesle duyurmuyor. Ama geliştiricileri kendi araçlarına bağımlı hale getirmeyi sürdürüyor ve bir gün gelip o yatırımı tahsil edecek
  • npm baştan beri bir şirket değil miydi? Rug pull’un ne olduğunu bilmiyorum ve gerçekten çalışmayı bırakan bir şey oldu mu?
  • PSF ile PyPA’nın kendine gelip Python paketleme konusunda iyi bir hikâye ortaya koymasını memnuniyetle karşılarım
    Ama bugüne kadar ortaya koydukları şey, özünde “kurduğumuz sistem bize yardımcı olmayı engelliyor ve her hâlükârda bu bizim hatamız değil” diyen milyarlarca katkıcı blog yazısından ibaret oldu
    İç sistemlere ve iç siyasete o kadar gömülmüş görünüyorlar ki neden orada olduklarını bile artık bilmiyor gibiler
    Bu yüzden biri gerçekten işi iyi yapıp Astral gibi piyasayı ele geçirirse, bu tam da topluluk olarak hak ettiğimiz sonuç olur
    [1]: Burada kastettiğim iç siyaset. Garip aşırı sağcı “DEI işe alımı!” taşkınlıkları değil

• Bu araçlarda hâlâ otorite sorunu var
  PyPA tarafından onaylanmıyor olmaları onları cargo’dan ayırıyor. Aynı zamanda PyPA yıllardır kapsayıcı bir çözüm sunamadı ve Python paketleme ile geliştirme araçları artmaya devam etti. Daha sadece 3~4 yıl önce poetry ve pipenv, pip+virtualenv’in çözemediği Python paketleme sorunlarını çözüyor gibi görünüyordu
  Bence artık PyPA astral.sh gemisine binmeli, ama belli bir düzeyde kontrol olmadan bunu yapar mı bilmiyorum

  • Kısa süre önce öğrendim ki PyPA adındaki Python Packaging Authority’deki Authority aslında başta şaka niyetine konmuş: https://discuss.python.org/t/remove-the-authority-from-packa...
  • PyPA, diğer seçenekler yerine Pipenv’i onayladığı andan itibaren PyPA tavsiyelerini ciddiye almayı bıraktım
    Bana göre bu büyük ölçüde kişisel ilişkilerle ilgiliydi ve o sırada Pipenv felaketti. Niyeti iyiydi ama şirkette, yaygın kullanılan bağımlılıkların görece az olduğu depolarda bile lock file güncellemesini beklemek bir saat sürüyordu. Basitçe çalışmıyordu
    Pratikte PyPA’nın yaptığı zor teknik işe büyük saygı duyuyorum. Ama şu anda hangi araç paketini önerdiği pek umurumda değil. Topluluğun kullandığını kullanmanın ve “resmî” öneriler hakkında kaygılanmamanın daha iyi olduğunu düşünüyorum
  • Biraz dışarıdan bakan biri olarak PyPA’nın aslında ne olduğunu anlamak zor
    Katılımcı sayısı belirsiz ve PyPA’nın çekirdek Python ya da PSF ile ne kadar bağlantılı olduğu da net değil
    Gerçekten faydalı olacak onayın çekirdek Python projesinin kendisinden gelmesi gerektiğini düşünüyorum. İdeal bir dünyada resmî Python öğreticisi “Python’u şöyle kurarsınız” diye başlayıp uv kurulumunu anlatmalı; tıpkı resmî Rust belgelerinin rustup ve cargo’ya işaret etmesi gibi
    PSF’nin Astral’la bir tür ilişki kurup bir gün böyle bir gerçekliği mümkün kılmasını kuvvetle umuyorum
  • Dürüst olmak gerekirse bu noktada PyPA’yı umursamıyorum
    Bu bağlamda büyük ölçüde alakasız olduğunu kendi kendine kanıtladı diye düşünüyorum. El attığı her şey çürüyormuş gibi görünüyor; bu yüzden üzülerek söylüyorum ama bu meselede uzak durmasını isterim. Bunu söylemek acı veriyor ve kendi felsefeme de aykırı, ama sadece mevcut duruma dair bir değerlendirme bu. 10 yıldır tam zamanlı Python’la çalışıyorum ve diğer paketleme ekosistemleri fiilen Python’u bir turdan fazla geride bıraktı
    Artık “bu PyPA’nın uygulama sorunu mu, yoksa biçilen rol alanı mı yanlış” gibi nüansları da umursamıyorum. Böyle tartışmalara çekilmekten de sıkıldım

• Armin, uv'nin bu alana hakim olmasını savunuyor, ancak girişim sermayesi destekli olduğu için bir gün rug pull yaşanabileceğini de kabul ediyor
  Bu potansiyel soruna çözüm olarak “fork'lamak çok kolay” diyor, ama fork'lar doğası gereği daha fazla parçalanma yaratmaz mı? Tam da onun çözmek istediği sorun bu değil mi?
  Python paketleme ekosistemine hakim olmaya çalışan bir araç varsa, bunun topluluk tarafından yönlendirilip topluluk tarafından kontrol edilmesi gerektiğini düşünüyorum

  • Fork'lamak özünde daha fazla parçalanma yaratmaz
    Önce tek bir rug-pull riski taşıyan araç etrafında birleşip sonrasında yaşanacak parçalanma düzeyi, birleşmeden önceki durumdan çok daha düşük olabilir
    Ayrıca bu hayali topluluğun gerçekten harika, baskın bir aracı ortaya çıkarması için daha onlarca yıla mı ihtiyacı var?
  • Lisans seçimi MIT ya da Apache olduğu için kolayca fork'lanabiliyor olabilir, ama Rust seçimi gerçekten katkı sunabilecek kişi sayısını sınırlıyor
  • npm de girişim sermayesi destekli değil mi?

• Bu sabah iş yerinde Poetry'nin yavaşlığı yüzünden yazılımımızı Poetry'den uv'ye taşımayı inceledim
  Şu ana kadar çok sayıda belge okuyorum ama fiilî ilerleme pek yok. Daha önce Poetry'ye geçiş işini de ben yapmıştım ve o zaman çok daha basitti. Şimdiye kadar gördüğüm kadarıyla Poetry, diğer paket yöneticileri gibi çalışan basit bir paket yöneticisi yapmaya çalışıyordu; uv ise Python paketlemenin çılgınlığının epey büyük bir kısmını olduğu gibi koruyor gibi görünüyor

  • En azından uv, Poetry'nin virtualenv ile çakışıp ortalığı tamamen dağıtması gibi şeyler yapmıyor
    Poetry'de küçük bir değişiklikle package.toml biçiminin bozulması ya da geçişli bağımlılıklarda çalışmayan saçma “sources” yüzünden birden fazla indeks üzerinde çözümleme süresinin uzaması gibi dertler yok
  • uv'de zor gelen şeyin tam olarak ne olduğunu biraz daha somut paylaşabilir misin?
  • Kısa süre önce pip-tools'dan uv'ye geçtim ve oldukça sorunsuzdu
    uv, aslında standart Python araç akışına doğrudan takılan bir şey gibi hissettiriyor
  • Belki de şu anda uv fazla düşük seviyeli; aslında istediğin şey Rye olabilir miydi?
  • Hangi çılgınlıktan bahsediyorsun?

• İnsanlar bu turu pas geçip 2026 sürümü olan “Python paket yöneticisi: bu kez gerçekten çözdük!”ü beklerse onları suçlamam
  Yine de ben hâlâ memnun bir Nix kullanıcısıyım

• Bu çerçevelemeyi gerçekten beğendim
  Uzun süre boyunca pek çok kişinin adım adım biriktirdiği emek sayesinde artık birkaç kişinin tek bir şirket içinde orta düzey bir çabayla durumu ciddi biçimde iyileştirebileceği bir noktaya gelindi