Python Paket Yöneticisi uv: Hızıyla Göz Kamaştırıyor, UX’iyle Tartışılıyor
Astral’ın Python dünyasına sunduğu uv, hızı, Python versiyonlarını kolayca yönetmesi ve birçok aracı tek bir ikilide birleştirmesiyle büyük ilgi topladı. Yeni bir Python projesi başlatmak ve ilk bağımlılıkları eklemek uv ile oldukça kolaydır. Ancak, projenin bakım aşamasına geçildiğinde, yani güncel olmayan paketleri kontrol etme ve rutin yükseltmeler yapma zamanı geldiğinde, uv’nin komut satırı arayüzü (CLI) pnpm veya Poetry gibi rakiplerine kıyasla şaşırtıcı derecede karmaşık hissettiriyor.
Güncel Olmayan Paketleri Bulmak
JavaScript projelerinde güncel olmayan paketleri görmek için genellikle $ pnpm outdated komutu kullanılır. Bu komut, güncel olmayan paketlerin net, özlü bir listesini sunar: mevcut sürüm, en son sürüm ve kısıtlamaların izin verdiği sürüm. Ancak uv’de özel bir uv outdated komutu bulunmuyor. Bunun yerine, $ uv tree --outdated --depth 1 gibi uzun bir komutu ezberlemek gerekiyor. Çıktı da sorunlu; sadece güncel olmayanları göstermekle kalmıyor, tüm üst düzey bağımlılık ağacını listeliyor ve güncellenebileceklerin yanına küçük bir açıklama ekliyor. Eğer 50 bağımlılığınız varsa ve sadece ikisi güncel değilse bile, 50 satırlık bir listeyi taramanız gerekiyor. Poetry’nin poetry show --outdated komutu da çok daha iyi olmasa da, en azından yalnızca gerçekten güncel olmayan paketleri gösterir.
Varsayılan Olarak Güvenli Olmayan Sürüm Kısıtlamaları
Bu, uv’nin pnpm ve Poetry’den ayrıldığı en önemli felsefi noktadır ve üretim istikrarı için tehlikeli bir durumdur.
pnpm/Poetry Bunu Nasıl Ele Alır?
pnpm add ile bir paket eklendiğinde, bu paket package.json dosyasına caret gereksinimi (^1.23.4) kullanılarak yazılır. Başlangıçtaki caret, herhangi bir 1.x.x sürümünün izin verildiği anlamına gelir, ancak 2.0.0 sürümüne otomatik olarak yükseltme yapmaz. Poetry de varsayılan olarak benzer bir format kullanır (örneğin >=1.23.4,<2.0.0). Her iki durumda da, **güncellemeler varsayılan olarak güvenlidir**. Her sabah pnpm update veya poetry update çalıştırabilir ve büyük bir API değişikliği nedeniyle yapınızın bozulmayacağından (paketler SemVer’e uyuyorsa) yüksek bir güvenle emin olabilirsiniz.
uv Bunu Nasıl Ele Alır?
uv add pydantic komutu çalıştırıldığında, bu pyproject.toml dosyasına şu şekilde eklenir: dependencies = ['pydantic>=2.13.4']. Üst sınırın eksikliği dikkat çekicidir. uv’nin gözünde, pydantic’in 2, 3 ve hatta 100. versiyonu tamamen kabul edilebilir. Bu, uv güncellemelerinin **varsayılan olarak güvenli olmadığı** anlamına gelir. Toplu bir güncelleme yaptığınızda, sadece hata düzeltmeleri almakla kalmaz, aynı zamanda bağımlılık grafiğinizdeki her geliştirici tarafından yayınlanan her türlü kırıcı değişikliği de kabul etmiş olursunuz.
Yükseltme Komutunun Kötü Kullanıcı Deneyimi
uv’deki güncelleme komutları, insanlar yerine makineler için tasarlanmış gibi hissettiriyor. pnpm veya Poetry’de her şeyi güncellemek için basit bir pnpm update veya poetry update komutu yeterlidir. uv’de ise $ uv lock --upgrade kullanılır. Yukarıda belirtilen ‘üst sınır yok’ sorunu nedeniyle, uv lock --upgrade nükleer bir seçenektir. Kilit dosyanızdaki her paketi, SemVer güvenliğini göz ardı ederek en son sürümlerine yükseltir; buna derin, iç içe geçmiş bağımlılıklar da dahildir! Bu durumun çok riskli olduğunu fark ettiğinizde, yalnızca belirli paketleri yükseltmek isteyeceksiniz. Ancak uv tree --outdated --depth 1 komutunun yetersiz çıktısını taradıktan sonra, sözdizimi tekrarlayan bir angarya haline gelir. pnpm’de: $ pnpm update pydantic httpx uvicorn. uv’de: $ uv lock --upgrade-package pydantic --upgrade-package httpx --upgrade-package uvicorn. Her öğe için --upgrade-package bayrağını tekrarlamak, birçok paketi güncellemek istediğinizde büyük bir zahmettir.
Umut Veren Bir Işık: –bounds Bayrağı
Neyse ki uv, yakın zamanda uv add için --bounds seçeneğini tanıttı: $ uv add pydantic --bounds major. Bu, beklediğimiz daha güvenli pydantic>=2.13.4,<3.0.0 kısıtlamasını üretir. Ancak bu, şu anda isteğe bağlı bir özelliktir. Her seferinde yazmayı hatırlamanız gerekir ve şu an itibarıyla bir önizleme özelliği olarak kabul edilmektedir. --bounds major (veya benzer bir yapılandırma) varsayılan davranış haline gelene kadar, uv kullanıcıları esasen iki kötü seçenek arasında seçim yapmaya zorlanıyor: her bağımlılık için pyproject.toml dosyasını manuel olarak düzenleyerek üst sınırlar eklemek veya uv lock --upgrade komutunun yanlışlıkla büyük bir sürüm değişikliği getirmesi korkusuyla yaşamak.
Gelecekten Beklentiler
uv’nin hızı dönüştürücü ve Python araç zincirlerini yönetme şekli eşsizdir. Ancak bir paket yöneticisi olarak, bir projeyi sürdürme konusundaki geliştirici deneyimi, önceki araçlara kıyasla şu anda bir adım geridedir. Gürültüyü filtreleyen özel bir uv outdated komutuna, bayrakları tekrarlamayı gerektirmeyen daha ergonomik bir update komutuna ve Semantik Sürümlemeye saygı duyan varsayılan sürüm kısıtlamalarına ihtiyacımız var. O zamana kadar, kilit dosyası değişikliklerinin her satırını sağlıklı bir şüphe dozajıyla iki kez kontrol edeceğiz.
