Rye: Zahmetsiz Python Deneyimi

 (rye.astral.sh)
2 puan yazan GN⁺ 2024-07-10 | 2 yorum | WhatsApp'ta paylaş
  • Rye, Python kurulumu, pyproject.toml projeleri, bağımlılıklar, virtualenv ve genel araç kurulumlarını tek bir yerde ele almayı amaçlayan bir proje ve paket yönetim aracıydı
  • Şu anda geliştirilmesi durduruldu ve aynı bakımcıların geliştirdiği halef proje uv'nin kullanılması öneriliyor
  • Mevcut kullanıcılar uv migration guide'a bakarak geçiş yapabilir; Rye hâlâ indirilebilir, ancak artık başka bir güncelleme planı yok
  • Güncellemelerin durması güvenlik güncellemelerini de kapsadığından, yeni projelerde veya uzun süreli bakım gerektiren ortamlarda uv'ye geçiş değerlendirilmeli
  • Rye'ın hedeflediği birleşik Python deneyimi, karmaşık projeleri ve monorepo'ları da kapsıyordu, ancak bakım odağı uv'ye kaydı

Rye'ın mevcut durumu

  • Geliştirmenin durdurulması ve uv önerisi

    • Tüm kullanıcılara uv kullanmaları öneriliyor
    • uv, aynı bakımcıların geliştirdiği halef proje
    • uv aktif olarak bakımı yapılan bir proje ve Rye'dan çok daha yaygın kullanılıyor
    • Mevcut Rye kullanıcıları uv migration guide'a başvurabilir
    • Rye kullanılmaya devam edilebilir, ancak ek güncelleme planı yok
    • Güvenlik güncellemeleri de planlanmıyor

Rye'ın sunduğu özellikler

  • Rye, Python için bir proje ve paket yönetimi çözümü
  • Python kullanıcıları için hepsi bir arada bir araç olmayı hedefleyerek geliştirildi
  • Tek bir birleşik deneyim içinde şu işleri ele alıyordu
    • Python kurulum yönetimi
    • pyproject.toml tabanlı proje yönetimi
    • Bağımlılık yönetimi
    • virtualenv yönetimi
    • Genel araç kurulumu
  • Karmaşık projeleri ve monorepo'ları ele alabilecek şekilde tasarlandı
  • Tanıtım videosu Watch an introduction bağlantısından izlenebilir

İlgili okumalar

2 yorum

 
lum7671 2024-07-11

Bir süredir, şunu bunu kullandıktan sonra
Introduction - PDM
kullanıyorum.

Sanırım Rye'ı da denemem gerekecek.
 
GN⁺ 2024-07-10
Hacker News yorumları

  • Temel paketleme geliştirmelerinin önemli bir kısmı artık uv üzerinde yapılıyor ve Rye da dahili olarak uv kullandığı için uv geliştikçe Rye da gelişiyor
    Örneğin yakın zamanda uv'ye evrensel bağımlılık çözümleme eklendi; böylece yalnızca şu anda çalışan sistem için değil, tüm platformlar ve işletim sistemlerinde çalışan tek bir çözümleme sonucuyla kilitlenmiş bir requirements.txt oluşturmak mümkün oldu ve en güncel Rye da bunu destekliyor
    https://github.com/astral-sh/uv
    Rye ve uv geliştiriyorum, sorunuz varsa yanıtlayabilirim

    • Rye/UV'nin evrensel bağımlılık çözümlemesi PyTorch ile de düzgün çalışıyor mu, yoksa Poetry ile benzer sorunlar mı yaşıyor merak ediyorum
      https://github.com/python-poetry/poetry/issues/6409
      https://news.ycombinator.com/item?id=39257501
    • Çapraz platform kilit dosyaları için yapılan çalışmaları veya planları takip edebileceğimiz bir yer var mı merak ediyorum
      Ekibimin geçişte tereddüt etmesinin nedenlerinden biri bu. ML işi yaptığımız için PyTorch tabanlı projeyi örnek verirsem, istediğimiz durum tüm bağımlılıkları pyproject.toml içinde tutup AArch64 Mac veya AMD64 Windows iş istasyonundan şu platform yapılandırmaları için kilit dosyaları üretebilmek: varsayılan MPS PyTorch kullanan Mac, CUDA PyTorch kullanan Windows, CPU PyTorch kullanan AArch64 Linux, CPU PyTorch kullanan AMD64 Linux, CUDA PyTorch kullanan AMD64 Linux
      Ruff'u yaptığınız için teşekkürler, hem linting hem formatting tarafında fazlasıyla memnunum
    • Harika iş. Eskiden yeni bir bilgisayarda proje çalışma ortamını arada bir kurmam gerekiyordu ve pyenv+venv+pip her zaman acı vericiydi, ama artık Rye'a geçtim
      Şimdi Rye'ı kur, GitHub'dan çek, rye sync yaz, bitti
    • Hem uv hem rye ile ilgileniyorsanız neden ikisini aynı anda sürdürdüğünüzü merak ediyorum. Parçalanma ve seçim yükü kaynaklı kafa karışıklığını önlemek için rye'ı şimdi sonlandırmak daha iyi olmaz mı?
    • Öngörülebilir ve performanslı build'lere önem veren çok sayıda şirket geçiş yapıyor ve bu süreçte guac gibi araçlara vermek üzere SBOM üretimi sık sık gerekiyor
      https://guac.sh/
      https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
      Yakın zamanda eklenen bağımlılık sabitlemesini kaldırma özelliği sayesinde geliştirme sırasında uyumluluğu korumaya teşvik edip, yeniden üretilebilirlik için doğru ve açık bir requirements.txt üretebilmek mümkün; bu da zafiyet yönetimi ve SBOM aşamasını Poetry gibi araçlara göre çok daha kolay hale getiriyor
      Benzer nedenlerle https://hatch.pypa.io/latest/why/ kullanıyorum ve uv ile iyi uyum sağlaması da hoşuma gidiyor

  • Rye'da beni rahatsız eden şeylerden biri, standart dışı Python build'leri kullanımını güçlü biçimde teşvik etmesi
    Felsefe sayfasında(https://rye.astral.sh/philosophy/) python.org'daki CPython build'lerinin tamamen yetersiz olduğu, platforma göre yalnızca .msi kurulum dosyası ya da sadece tarball bulunduğu ve çeşitli Python dağıtımlarının ciddi biçimde ayrışarak alt ekosistemde her türlü soruna yol açtığı anlatılıyor. Bu yüzden proje indygreg standalone build'lerini kullanıyor ve bir gün iyi yönetilen, güvenilir Python build'lerinin çıkıp bugünkü karmaşayı ortadan kaldırmasını umuyor
    Bu indygreg build'leriyle ilgili bilgiler burada: https://gregoryszorc.com/docs/python-build-standalone/main/ ve başka Python sürümleri seçmek de mümkün: https://rye.astral.sh/guide/toolchains/
    Ama ben onların sözünü ettiği sorunların neredeyse hiçbirini yaşamadım. python.org'dan indirilen resmi Python build'i de çalıştı, dağıtımın paket yöneticisiyle kurulan sıradan Python da çalıştı, resmi Docker container image içindeki Python da çalıştı
    O özel build'ler de muhtemelen iyi çalışıyordur, ama standart dışılıkları yüzünden tereddüt ediyorum. Hatta davranış farklılıklarının listesi bile var; sorun olmayan bir şeye neden farklılık ekleniyor anlamıyorum. Rye felsefesinin bu build'leri kullanma konusunda bu kadar istekli olması da, işletim sisteminde zaten bulunan Python'ı varsayılan kullanan alternatiflere kıyasla cazibesini azaltıyor

    • Sanırım kastedilen durum şu tür bir şey: eski bir CentOS benzeri kullanan bir şirkette çalışıyorsunuz, sistem paket yöneticisi Python 3.6'dan yenisini vermiyor ve python.org'un resmi ikili dosyası çalıştırıldığında glibc sürümü hakkında anlaşılmaz bir hata veriyor
      Python'ı kaynaktan build etmeye kalktığınızda yeni sistem bağımlılıkları gerekiyor, işlem uzun sürüyor ve sonunda eksik header dosyaları hakkında yine anlaşılmaz bir hata alıyorsunuz. Bu hatayı arattığınızda upstream GCC'nin 2017'de düzelttiği bir sorunu dolanan bir ./configure bayrağı buluyorsunuz ve bir şekilde sonuçta başarıyorsunuz
      Eğer bu tür üçüncü hata sınıfını ya da manylinux build ortamını hiç yaşamadıysanız, tam bir acı dünyasını pas geçmişsiniz demektir. Windows kurulumunu script'lemek ya da o sayfadaki “kullanılabilir CPU komutları sınırlamaları” gibi konular da buna dahil
    • Python build etme, paketleme ve dağıtımında iki uç var. Biri kraliyet yolu, diğeri ise bin bıçaklı bir koridor. Taşınabilir Python önerisi size mantıklı gelmiyorsa şanslısınız demektir; yani şimdiye kadar hep kraliyet yolunda kaldınız

  • Python kaynak kodunu düzenli olarak indirip standart üretim optimizasyonlarıyla derleyerek /use/local/python${version} altına kuruyorum; bu yöntem Python 3.7’nin çıktığı 2018’den beri son derece tutarlı çalışıyor.
    Benim deneyimime göre bu komutlar o kadar kararlı ve tutarlı ki otomasyona bile alınabilir. Yazarın tam olarak hangi noktayı sorun ettiğini ya da temel itirazının ne olduğunu merak ediyorum

    • “python.org’daki CPython derlemeleri tamamen yetersiz” sözü muhtemelen eski Python sürümlerinin güvenlik yayınları için macOS/Windows ikilileri bulunmaması anlamına geliyor olabilir.
      Örneğin Python 3.10.14 kurulum paketini indiremiyorsunuz; son Windows kurulum paketi Python 3.10.11, 5 Nisan 2023 tarihli sürüm
    • Katılıyorum. PSF’yi desteklemek gerekir; yeni bir “doğru yöntem” iddia etmek tuhaf bir duruş

  • Rye’ı seviyorum. Vadettiği işi gerçekten yapıyor; venv/Python sürümü/paketleme sürecinin tamamını fiilen keyifli hale getiriyor ve pyproject.toml gibi resmî Python kullanım biçimlerine alışkın olanlar için neredeyse görünmez hissettiriyor.
    Üstelik Python’u Cargo gibi hissettiriyor; Cargo da kullanması keyifli bir araç

    • Benim gibi Poetry tarzı araçları es geçip pip-tools ile kaldıysanız, Rye’ın içinde kullandığı uv doğrudan ikame edilebilecek bir araç.
      Bana göre pip-tools, Poetry ya da Pipenv’den çok daha iyi tasarlanmıştı. Hem pip hem de virtualenv ile ortogoneldi ve ikisi de zaten Python’da uzun süredir yerleşik akışlardı. Rye, tekrar tekrar iyileştirilmiş, standartlara uyan yaklaşımın kazandığını gösteriyor denebilir.
      Rust sayesinde gelen hız artışının ötesinde, sanal ortamın nereye konacağı (.venv) ve birden fazla Python sürümünün nasıl kurulacağı konusunda iyi varsayılanlar sunmasını seviyorum. Küçük görünüyor ama wheel’lerin numpy kurulum sorununu çözmesinden beri gerçekte eksik olan şey tam da böyle makul varsayılanlar ve yerleşik pip-tools’tu. Bu açıdan bakınca, ikili wheel’ler geldikten sonra Anaconda’nın varlık sebebinin ne olduğunu da merak ediyorum
    • Python’da her şey için tek bir yol olduğu söylenerek başlamıştım ama kurulum ve ortam yönetimi deneyimi tam bir karmaşaydı.
      Hiç değilse şimdi düzeliyor olmasına sevindim
    • “Python’u Cargo gibi hissettiriyor” diyorsanız beni hemen ikna eder. Poetry bütün gün sürüp yine de bağımlılıkları çözemeyince pixi denemeyi düşünüyordum.
      Python paket yöneticilerinin sayısı sanki Google sohbet uygulamalarından bile fazla
    • “Fiilen keyifli hale getiriyor” ile tam olarak ne kastedildiğini merak ediyorum. Bunu özetlemek fazla mı zor? Anaconda ya da Poetry’de kullanıcı deneyimi açısından özellikle tercih sebebi gibi görünen bir yön pek bulamadım.
      Ayrıca seçme ölçütü olarak, büyük ve köklü organizasyonlar yerine daha küçük organizasyonlara güvenme önerisi çok ikna edici gelmiyor. Yani tam olarak ne vadettiğini merak ediyorum. Benim okuyabildiğim şey en fazla “iyi paket yöneticisi iyidir, hızlıdır ve iyidir” seviyesinde; bir karşılaştırma ya da felsefe sayfası olsa iyi olurdu

  • HN’deki alaycılık bazen beni şaşırtıyor.
    Rye’ı seviyorum. Cargo ya da Hex gibi diğer dillerin paket yöneticilerini kullandıktan sonra Python’da benzer bir sistemin olmaması hep eksiklik gibi geliyordu; Rye bu ihtiyacı benim için tamamen giderdi. venv, Python sürümü ve proje bağımlılıklarını yönetmek için birden fazla araç kurmak istemeyen biri olarak her şeyi tek başına Rye’ın halletmesi gerçekten çok hoş

    • conda kullandınız mı merak ediyorum. conda ile karşılaştırınca Rye nasıl?
      Rye hakkında henüz bir hissim yok ama conda da venv, Python sürümü ve proje bağımlılıklarını gayet iyi yönetebiliyor
    • Katılıyorum. Rye bende iyi çalışıyor. Python için Cargo istiyordum ve şu ana kadar benim açımdan Rye bunu başardı

  • Yeni bir Python bağımlılık yöneticisiyle karşılaşmak, yeni bir JavaScript framework’üne rastlamak gibi

    • Benim felsefem basit. Eğer dağıtılabilir bir program olacaksa doğrudan Go kullanırım; port gibi bir ihtiyaç yoksa Docker kullanırım; eğer şirkette herkesin kullandığı işletim sistemi ve Python sürümünün kurulu olduğu bir bilgisayarı IT ya da bir başkası size veriyorsa venv kullanırsınız.
      Eğer portlarla uğraşmanız gerekiyorsa, program dağıtmanız gerekiyorsa ya da kütüphane C’ye veya işletim sistemi bileşenlerine bağımlıysa, para alındıktan sonra kod tabanını yönetmek ya da sorumluluğunu taşımak zorunda kalmayacağınız danışmanlık işine geçmek daha iyi olur
    • Doğru. Docker aslında yaklaşık 10 yıl önce Python programlarını dağıtma ve çalıştırma sorununu çözmüştü.
      Artık Docker içinde CUDA ve PyTorch da çalıştırılabiliyor. Bu tür başlıklarda biri “Docker kullanın yeter” dediğinde sık gelen cevap “Docker öğrenmek istemiyorum” oluyor ama Docker konusunda hiç deneyimi olmayan biri bile 10 dakikada bir Python container’ı ayağa kaldırabilir
    • Evet, ama Poetry gibilerinin aksine bu seferki gerçekten iyi
    • Gerçekten ciddi bir durum. Kullanıcı açısından bakınca, bunca yıldan sonra hâlâ bir standart olmaması sinir bozucu

  • pixi(https://pixi.sh/latest/) iyi görünüyor. Python sürümünü sabitleyebiliyor, paketleri conda ve PyPI’dan kurabiliyor ve Rust ile yazılmış

    • İlginç görünüyor ama bir başka ekosisteme ciddi biçimde yatırım yapmak zor geliyor. curl ile indirip bash’e pipe etmenizi istemesi, sonra da rastgele komut çıktısına eval demesi rahatsız edici
    • Link için teşekkürler. conda’dan daha hızlı olup olmadığını merak ediyorum
    • pixi harika. conda kullanan biri için pixi, Git/proje dizinine bağlı ortamlar kullanan bir conda alternatifi olabilir; devbox/devenv/flox’a benziyor.
      Arka plan biraz karmaşık. Önce Anaconda şirketinin Python ile yazdığı conda vardı; açık kaynak ekosistemi olan conda-forge ise CI derleme botlarına sahip bir conda kanalı. Sonra yine aynı conda-forge çatısı altında, C++ ile yazılmış mamba conda’ya alternatif olarak ortaya çıktı; bu gerçekten alias conda=mamba çalıştırılabilecek düzeyde bire bir yerine geçebilen bir alternatif. Şimdi conda da hız kazanmak için çözücü olarak libmamba kullanıyor.
      Daha sonra mamba’nın yazarı bunu pixi olarak ayırdı; Rust ile yeniden yazarken ortamların konumu ve etkinleştirilme biçimi konusundaki felsefeyi değiştirdi ama conda ortamlarıyla tamamen uyumlu kaldı

conda, conda kanalında olmadığında pip üzerinden PyPI paket kurulumunu her zaman destekledi; pixi ise PyPI paketlerini uv üzerinden destekliyor. Bu yüzden pixi hızlı. Blog yazısına göre, onu mamba'dan bile çok daha hızlı yapan başka optimizasyonlar da var
Saf Python olmayan paketler kullanıyorsanız conda ailesi doğru seçimdir. Paket yöneticisi seçimi (conda/mamba/pixi) ikincildir
PyPI'nin sorunu, yeterli bir bekçilik mekanizmasının olmaması. Buna, saf Python olmayan paketleri standart biçimde paketleme yöntemlerinin yetersizliği eklenince ortam sızıntıları oluyor; özellikle sadece kaynak dağıtıp setup.py içinde derleyiciye kadar ortamı bootstrap eden tuhaf şeyler yapıldığında yeniden üretilebilirlik kayboluyor
conda tarafında conda-forge kanalı oldukça iyi kalite kontrolü yapıyor. Kısıtları, lisansları, PyPI dağıtımlarında lisans dosyasının eksik olması sorununu ve ortam yalıtımını kontrol ediyor. Elbette, bakımcıların yanlış sürüm kısıtlarına sahip PyPI değişikliklerini otomatik birleştiren resmî botu kullanabilmesi nedeniyle kusursuz değil
Şu anda hiçbir aracın çözemediği sorun PyPI merkezli. conda'da olmayan paketlerle uğraşmak gerekiyor ve paket sürümlerini de fiilen önce PyPI'de yayımlamak zorunlu hale geliyor
Yalnızca PyPI'de bulunan bir paketi conda üzerinden kurarken, onun bazı bağımlılıkları conda'da olabilir. Bildiğim kadarıyla, PyPI paket bağımlılıklarını karşılamak için conda paketlerini kullanan bir paket yöneticisi yok. Bağımlılıkları elle karşılamak için conda paketleri eklenebilir, ama doğru sürüm kısıtlarının uygulanmaması riski var
Açık kaynak Python paketleri yazarken de, yapılandırma yalnızca conda kanalına dayansa bile çoğu durumda önce PyPI'de sürüm yayımlamak gerekiyor ya da en azından gerekiyor gibi. Çünkü conda-forge kanalındaki sürüm yayını fiilen PyPI varlığını şart koşuyor. Bu yüzden benim gibi biri için de Rye hâlâ faydalı olabilir ve bakmaya değer

  • uv tarafındaki kişilerin(https://astral.sh/blog/uv) bu Armin projesinin yönetimini devraldığını bilmekte fayda var
  • Tanıtım sayfasında “Rye is still a very experimental tool, but this guide is here to help you get started.” yazıyor
    Bu proje beni çok heyecanlandırıyor ama daha olgun bir aşamaya gelene kadar beklemeyi planlıyorum. Astral ekibinin çıkardığı diğer şeylerin hepsini sevdiğim için beklentim yüksek
  • Biz openai-python kütüphanesinin geliştirilmesinde rye kullanıyoruz ve çok memnun kaldık
  • Rye iyi görünüyor ve Poetry'yi de oldukça keyifle kullandım, ama Go'nun yerleşik araçlarının kalitesi gerçekten saygı uyandırıyor
    Python projesine her başladığımda bağımlılık/sanal ortam yönetimindeki güncel durumu yeniden öğrenmem gerekiyormuş gibi hissettiriyor