uv harika ama paket yönetimi UX'i berbat

 (loopwerk.io)
2 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • uv; yüksek hızı, Python sürüm yönetimi ve tek bir ikili dosyada birleşik yapı sunmasıyla güçlü, ancak bakım aşamasındaki paket yönetimi UX'i hâlâ kaba
  • Eski paketler uv pip list --outdated ile görülebiliyor, ancak bu üst düzey bir komut değil; pip uyumlu ad alanı altında olduğu için keşfedilebilirliği düşük
  • uv add pydantic, varsayılan olarak pydantic>=2.13.4 gibi üst sınırı olmayan kısıtlar ekliyor; bu da majör sürüm artışlarına da izin veriyor
  • Toplu yükseltme uv lock --upgrade ile yapılıyor ve birden fazla belirli paket için --upgrade-package tekrar etmek gerekiyor; bu da komutu gereksiz yere uzatıyor
  • add-bounds = "major" ayarıyla daha güvenli varsayılan kısıtlar verilebiliyor, ancak bu bir önizleme özelliği ve uygulamalar için daha sezgisel bir güncelleme UX'ine ihtiyaç var

uv'nin güçlü yanları ve bakım aşamasındaki sıkıntılar

  • Astral'ın uv aracı; yüksek hızı, Python sürüm yönetimi ve birden fazla aracı tek bir ikili dosyayla değiştirebilmesiyle öne çıkıyor
  • Yeni bir Python projesi başlatmak ve ilk bağımlılığı eklemek kolay, ancak proje bakım aşamasına geçtiğinde eski paketleri kontrol etme ve düzenli yükseltme UX'i pnpm veya Poetry'ye kıyasla daha hantal hissettiriyor
  • Temel sorunlar; eski paketleri gösteren komutun keşfedilebilirliği, varsayılan sürüm kısıtlarında üst sınır olmaması ve yükseltme komutlarının gereğinden uzun olması

Eski paketleri kontrol etme

  • JavaScript projelerinde pnpm outdated, eski paketleri, mevcut sürümü, en güncel sürümü ve kısıtlar nedeniyle izin verilen sürümü kısa ve net şekilde gösteriyor
  • uv'de üst düzey bir uv outdated komutu yok ve başlangıçta şu komut alternatif olarak kullanılıyordu
$ uv tree --outdated --depth 1
  • uv tree --outdated --depth 1, yalnızca eski öğeleri filtrelemek yerine tüm üst düzey bağımlılık ağacını yazdırıyor ve güncellenebilecek öğelerin yanına küçük notlar ekliyor
  • 50 bağımlılık varsa ve bunların yalnızca 2'si eskiyse bile 50 satırlık listeyi taramak gerekiyor
  • Poetry'nin poetry show --outdated komutu da isim olarak daha az sezgisel, ancak çıktısı gerçekten yalnızca eski paketleri gösteriyor

Varsayılan sürüm kısıtlarının riski

  • pnpm ve Poetry'nin varsayılan yaklaşımı

    • pnpm add, package.json içine ^1.23.4 gibi bir caret gereksinimi yazıyor
    • ^1.23.4, 1.x.x sürümlerine izin verir ama 2.0.0'a güncellemez
    • Poetry de varsayılan olarak >=1.23.4,<2.0.0 gibi bir biçim kullanıyor; yazımı daha az okunaklı olsa da etkisi aynı
    • Bu iki araçta, paketin SemVer'e uyduğu varsayımıyla pnpm update veya poetry update çalıştırmak ana API değişiklikleri yüzünden derlemenin bozulma olasılığını azaltıyor

  • uv'nin varsayılan yaklaşımı

    • uv add pydantic, pyproject.toml dosyasına aşağıdaki gibi üst sınırı olmayan bir kısıt ekliyor
dependencies = [
    "pydantic>=2.13.4",
]
  • Bu kısıt altında pydantic 2, 3, hatta 100 sürümleri bile kabul ediliyor
  • Toplu güncelleme çalıştırıldığında yalnızca hata düzeltmeleri değil, bağımlılık grafiğindeki tüm bakımcıların yayınladığı geriye dönük uyumluluğu bozan değişiklikler de alınabiliyor
  • Özellikle uygulama bakımında bu durum kararlılık riski yaratabiliyor

Yükseltme komutlarının UX'i

  • pnpm ve Poetry'de toplu güncelleme şu kadar basit
$ pnpm update
$ poetry update
  • uv'de toplu yükseltme için şu komut kullanılıyor
$ uv lock --upgrade
  • uv lock --upgrade, uv update ya da uv upgrade değil; lock komutunun bir seçeneği olarak çalışıyor, bu yüzden insanların kullandığı paket yönetimi komutları açısından daha az sezgisel
  • Üst sınırı olmayan kısıtlarla birleştiğinde uv lock --upgrade, lockfile içindeki tüm paketleri mutlak olarak en yeni sürüme çıkarma anlamına geliyor
  • Bu güncelleme, doğrudan farkında olmadığınız derin iç içe bağımlılıkları da içerebilir
  • Belirli paketleri güncellemek için pnpm'de paket adlarını şöyle sıralamak yeterli
$ pnpm update pydantic httpx uvicorn
  • uv'de ise her paket için --upgrade-package bayrağını tekrar etmek gerekiyor
$ uv lock --upgrade-package pydantic --upgrade-package httpx --upgrade-package uvicorn
  • Birden fazla paketi aynı anda yükseltirken tekrarlanan bayraklar büyük bir kullanım zorluğu yaratıyor

--bounds bayrağı ve ayar

  • uv'ye kısa süre önce uv add için --bounds seçeneği eklendi
$ uv add pydantic --bounds major
  • Bu komut, daha güvenli bir kısıt olan pydantic>=2.13.4,<3.0.0 üretiyor
  • --bounds major şu anda bir önizleme özelliği ve her komutta elle yazılması gereken, isteğe bağlı bir özellik
  • Sonrasında pyproject.toml içinde varsayılan değerin bir kez ayarlanabildiği ortaya çıktı
[tool.uv]
add-bounds = "major"
  • Bu ayar kullanıldığında her seferinde --bounds major yazmadan sonraki uv add komutlarında daha makul varsayılanlar elde edilebiliyor
  • Uygulamalarda bu davranışın varsayılan olması daha iyi olurdu, ancak gerçek kullanım kolaylığı ilk anlatıldığı kadar kötü değil

Uygulamalar ve kütüphaneler arasındaki fark

  • Python paketleme dünyasında standart tavsiye, PyPI'a dağıtılan kütüphanelerin üst sınır sabitlememesi yönünde ve bu tavsiye makul
  • Tüm kütüphaneler üst sınır koyarsa alt taraftaki kullanıcıların bağımlılık ağacı çözümlenemeyebilir
  • Buna karşılık uygulamalar, bağımlılık grafiğinin uç düğümüdür ve başka kullanıcılar bu kısıtları çözümleme için temel almaz
  • Uygulamalarda üst sınır koymanın bir maliyeti yoktur ve beklenmedik majör sürüm artışlarına karşı koruma sağlar
  • Buradaki kapsam; web siteleri, servisler ve iç araçlar gibi uygulama bakımını kapsıyor, kütüphane dağıtımında ise üst sınırı olmayan varsayılanlar makul olabilir

Düzeltilen noktalar ve kalan sorunlar

  • uv pip list --outdated kullanılarak yalnızca eski paketler filtrelenmiş şekilde görülebiliyor
$ uv pip list --outdated
  • Bu nedenle uv tree --outdated --depth 1 için yapılan gürültülü çıktı eleştirisi bir miktar zayıflıyor
  • Geriye kalan sorun, bu özelliğin üst düzey bir komut olmaması ve pip uyumlu ad alanı altında yer aldığı için keşfedilebilirliğinin düşük olması
  • add-bounds = "major" ayarıyla varsayılan bounds belirtilebildiğinden, üst sınırları her seferinde elle düzenlemek ya da riski kabul etmek gibi ikili bir durum tam olarak geçerli değil
  • Yine de bu özellik önizleme aşamasında ve uygulama paket yönetiminde daha güvenli varsayılan kısıtlarla daha sezgisel güncelleme komutlarına ihtiyaç var

Beklenen iyileştirmeler

  • Yalnızca eski paketleri açıkça gösteren özel bir uv outdated komutu gerekli
  • Birden fazla paketi güncellerken bayrak tekrarını gerektirmeyen, daha ergonomik bir update komutu gerekli
  • Varsayılan sürüm kısıtları, anlamsal sürümleme (SemVer) için beklenen kararlılığı daha iyi yansıtmalı
  • Mevcut durumda lockfile değişikliklerindeki her satırı şüpheyle inceleme yükü devam ediyor

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Hacker News görüşleri

  • uv add için varsayılan sürüm aralığı kalıcı ayar olarak belirlenebiliyor; böylece her seferinde vermek gerekmiyor
    Not: https://docs.astral.sh/uv/reference/settings/#add-bounds
    Varsayılan olarak üst sınır eklenmemesinin nedeni ekosistemde gereksiz yere çok sayıda çakışma yaratması ve Poetry kullandığım dönemde bununla ilgili kaynakları da toplamıştım: https://github.com/zanieb/poetry-relax#references

    • Kütüphane dağıtırken üst sürüm sınırlarını kaldırmanın önemli olduğunu anlıyorum, ancak yazı bir kütüphane değil bir web sitesi geliştirme perspektifiyle yazılmış
      Web projelerinde bağımlılık kullanırken, bağımlılıkların SemVer'a uyduğu varsayımıyla kırıcı değişiklikleri önlemek için üst sınır olmasını isterim
    • Haskell topluluğu da bu sorunla yıllarca uğraştı ve bir dönem en başarılı yaklaşım Stackage olmuştu
      Savunmacı üst sınırlar koymamayı teşvik ettiler, ekosistemin büyük ve aktif bir bölümünü her sürümde sürekli derleyerek gerçek uyumluluk sorunlarını buldular, sahiplerine otomatik bildirim gönderdiler ve bir sonraki "LTS" sürümünde kalmak için net bir takvim sundular
      Şu anda yalnızca Cabal çözücüsüyle bile durum epey kararlı görünüyor ama geniş kapsamlı gece derlemeleriyle görünür başarısızlıklar ve engellerin ekosistemin çözülebilir kalmasına yardımcı olmuş olması muhtemel
    • add-bounds ayarını ancak şimdi öğrendim; tam bağımlılık sabitlemesi önemli ama deneyimsiz geliştiricilerin kolayca gözden kaçırabileceği projelerde, özellikle kütüphane değil nihai ürün olan projelerde faydalı
    • --native-tls bayrağını kalıcı olarak ayarlamanın bir yolu olup olmadığını merak ediyorum
      İş yerindeki Zscaler yapılandırması yüzünden UV bu bayrak olmadan sürekli başarısız oluyor
      Ayrıca belirli bir mimariye uygun Python sürümü belirtmeyi destekleme planınız olup olmadığını da merak ediyorum. Şirket içinde bakımını yaptığımız bir paket 32 bit Python kullanmak zorunda, bu yüzden hep --python /path/to/32bit vermem gerekiyor
    • Biraz ham bir soru olabilir ama uv'nin pyproject.toml içindeki exclude-newer ayarına uymasını sağlamanın bir yolu olup olmadığını merak ediyorum
      uv run çalıştırınca exclude-newer pyproject.toml dosyasından kaldırılıyor
      Her seferinde uv run —-frozen ya da uv run --exclude-newer çalıştırabilirim ama bu doğru akış gibi gelmiyor; kaçırdığım daha idiomatik bir yol var mı diye merak ediyorum

  • uv, tek bir çözüm sonucu gerektirdiği için üst sınır olmaması bilinçli bir tasarım
    npm ağacın farklı bölümlerine farklı çözüm sonuçları kurabiliyor ama Python'da bu bir seçenek değil. Rye'da da aynı kararı vermek zorunda kalmıştık ve bunun daha iyi bir çözümü yok
    Üst sınır eklerseniz pratikte artık çözülemeyen ağaçlar oluşturabilirsiniz. Python paket ekosisteminin bazı bölümleri geçmişte yanlış üst sınır varsayımlarıyla yayımlanmış eski paketler için override bile yayımladı
    Bugün itibarıyla henüz yayımlanmamış bir paketle kendi paketinizin uyumlu olup olmayacağını bilemezsiniz

    • Ben şahsen güncelleme yaparken paketlerin uyumsuz olduğuna dair hatayı uv içinde almayı ve gerekirse override edebilmeyi tercih ederim
      Bunu, çalışma anında iz sürmesi zor sürüm uyumsuzluğu hatalarıyla karşılaşmaya tercih ederim
    • Asıl sorun pyproject.toml içinde üst sınır olmaması değil
      Asıl sorun uv lock —-upgrade komutunun üst sınırı olmayan her şeyi toplu halde yükseltmesi
      Major sürüm artırmadan paketleri yükseltmenin bir yolu olsaydı bu komut çok daha güvenli olurdu
    • uv birçok şeyi iyileştirdi ama temelde bunun önemli bir kısmı yalnızca araçlarla çözülebilecek gibi görünmüyor
      uv öncesine kıyasla çok daha iyi ama tüm ekosistemde belirli ölçüde kırıcı değişiklikler olmadan durumun tamamen düzelmesi zor görünüyor. Python 2'den 3'e geçişi düşününce, yakın vadede böyle bir değişim isteğinin de güçlü olacağını sanmıyorum
    • Kütüphane yazarları için bu doğru olabilir ama web sitesi geliştirip birçok pakete bağımlı olduğunuzda yükseltmeler sırasında güvenli olmak için üst sınır istersiniz
      —-bound bayrağı yardımcı oluyor ama yazıp hatırlanması gereken bir şey daha ekliyor
      uv bunun bir kütüphane projesi olmadığını anlayabiliyorsa varsayılan olarak üst sınır ekleyebilir diye düşünüyorum
    • Aslında ister uv ister npm olsun, doğru kullanımın yolu her şeyi = yapıp major olmayan güncellemelerin bozulmayacağına güvenmemek ve yalnızca elle güncellemek

  • Üretimde çalışan bir uygulamada 257 Python bağımlılığımız var ve bunların yarısından fazlası doğrudan bağımlılık
    pyproject.toml içinde üst sınır kullanmıyoruz ve iki haftada bir GitHub Actions ile uv lock --upgrade çalıştırıyoruz
    Test kapsamımız iyi olduğu için bir şey bozulursa testler başarısız oluyor; ayrıca yapay zeka destekli bir inceleme akışımız da var. Yükseltme PR'ı oluştuğunda yapay zeka iş akışı Python betiğiyle major/minor sürüm güncellemelerini listeliyor, değişiklik günlüklerini bulup bağlayıp özetliyor ve kod tabanında ilgili paketlerin nasıl kullanıldığına göre her paketin riskini analiz ediyor
    Genel olarak neredeyse hiç acı vermiyor; paketleri tek tek yükseltmek, eski paketleri kontrol etmek ya da terk edilmiş bağımlılıklarla uğraşmak gerekmiyor. Kod içinde çözülemeyip bağımlılık yazarının düzeltmesini gerektiren durumlar çok nadir; yaklaşık yılda bir oluyor. Son 3 ayda 18 major sürüm artışı oldu ve bunlardan yalnızca biri kod değişikliği gerektirdi
    Bunu frontend tarafında da yapmak isterdim ama güvenle çalıştıracak kadar test yok. Backend testleri yazması daha kolay ve daha kritik; bu yüzden her kod tabanında olması gerektiğini düşünüyorum. Testleriniz varsa her şeyi otomatik yükseltebilirsiniz

    • Test yazmak, yapay zeka ajanlarının da iyi olduğu bir iş
      En azından doğal dil talimatlarını doğru testlere dönüştürmede oldukça iyiler
      Bir süredir testleri elle yazmıyorum; eskiden hep şikâyet ettiğim bir şeydi ama artık değil

  • UV Python için çok şey yaptı ama bugün epey boğuştum
    Farklı depolara dağılmış ve zamanla uygulamaları birbirinden sapmış betikleri merkezi olarak yönetmeye çalışıyordum
    Aklımdaki yaklaşım uv run --with $package main --help idi ve otomatik olarak 1) yoksa kurup çalıştırmasını, 2) güncelse yeniden kurmamasını, 3) güncel değilse güncellemesini istiyordum
    Ama bu üçünün hepsi beklediğimden daha zordu. Temelde uv run her seferinde yeniden kurdu ve sanal ortam ile kurulum 6 saniye sürdü
    uvx ya da uv tool da çok daha iyi değildi; bu kez kullanıcıların yükseltme almaması gibi yeni bir sorun ortaya çıktı
    Sonunda betik CodeArtifact'a sayfalı GET isteği atıp daha yeni bir geliştirme dışı sürüm varsa güncelliyor ve tekrar çalıştırıyor. Çalışıyor ve 6 saniye yerine 200 ms gecikme daha iyi, ama istediğim deneyim bu değildi

    • uv run --with $package main --help dediğiniz davranışı çok az ek yükle yapmalı, bu yüzden biraz kafam karıştı
      Her seferinde yeniden kurmuyor; --with ortamı önbellekte tutuluyor ve korunuyor. Ortam önbelleğe alınmamış olsa bile bağımlılıklar önbelleğe alınıyor ve önbellekten kurulum çok hızlı oluyor. Kesinlikle 200 ms'nin altında olmalı
      Ayrıntılı bir yeniden üretim örneği açarsanız bakabilirim
    • Bu kullanım için uv tool install ve uv tool upgrade daha uygun görünüyor
      Yine de bu tür küçük pürüzler nispeten kolay çözülebilir gibi, o yüzden bir issue açmanız iyi olur
    • Dosyanın en üstündeki belge bloğunda gerekli bağımlılıkları tanımlayıp ardından sadece uv run main de çalıştırabilirsiniz
      Böylece gereken bağımlılıkları otomatik kurar, önbelleğe alır ve çalıştırır: https://docs.astral.sh/uv/guides/scripts/
    • Kullanıcılar neden sadece uv tool upgrade çalıştırmasın?
    • https://copier.readthedocs.io/en/stable/'e de bakılabilir
      Tam olarak aynı kullanım senaryosu mu bilmiyorum ama polyrepo mikroservis ekosistemini senkronize etmek için çok iyiydi

  • Eski bağımlılıkları görmek için "uv tree --outdated --depth 1" önerilmesine epey şaşırdım
    Ben kişisel olarak bu özellik geldiğinden beri "uv pip list --outdated" kullanıyorum
    Yine de bu kadar önemli bir komutun ayrı bir üst düzey alt komutu hak ettiği fikrine katılıyorum

    • Yazar açısından bu bir öneri değil, bildiği tek yoldu
      "uv pip list --outdated" çok daha iyi çıktı veriyor, teşekkürler
      Ama eski paketleri görmenin iki farklı yolu olması ve çıktılarının ciddi şekilde farklılaşması da UX'in kötü olduğunu düşündürüyor
    • "uv tree -od1" de muhtemelen çalışıyordur
      Ama pacman gibi paket yöneticilerine yönelik eleştirinin bir kısmı da apt gibi sık kullanılan işler için insanın anlayacağı komutlar sunmaları gerektiğiydi

  • Başlıktaki “berbat” ifadesine kıyasla örnekler daha çok birkaç ek argüman yazmak zorunda olmak gibi duruyor
    Daha iyi bir başlık UV'de görmek istediğim yaşam kalitesi iyileştirmeleri olurdu gibi

    • Bu ifade ve “bu komut satırı arayüzünü kim tasarladı” gibi sözler dikkat ve tıklama çekmek için seçilmiş görünüyor
      Geri bildirimin kendisi faydalı ve çoğuna katılıyorum ama bu tür ifadeler geri bildirimin değerini düşürüp savunmacı tepkileri tetikliyor
      uv'nin komut satırı arayüzünü ben de yorucu buluyorum ama neden böyle tasarlandığını anlayabiliyorum

  • uv harika ama bugün Python paketlemedeki en büyük sorun hâlâ bilimsel/makine öğrenimi paketleme tarafını düzgün ele almak
    PyTorch kurmak istiyorsanız önce hangi sürüm olduğu, CUDA gerekip gerekmediği düşünülmeli. CUDA ise CUDA sürümüne göre 6 farklı varyant var ve wheel'lar da PyPI'a koymak için fazla büyük olduğundan doğrudan indirmek gerekiyor
    Conda bu sorunu ancak kısmen çözüyor. Spack aşırı yapılandırılabilir; gerekli C/C++/Fortran bağımlılıkları ve derleyici araç zincirleriyle en yüksek performansı almak için harika ama uv ve benzerleriyle iyi entegre olmuyor. Bu da araştırmacılar tarafından geliştirilmiş deneysel makine öğrenimi projelerini üretime taşımayı zorlaştırıyor

    • Eskiden bunu Anaconda ile aşmaya çalışıyordum ama yanında çok fazla gereksiz şey geliyordu ve geliştirme ortamı üretim ortamından tamamen farklılaşıyordu; o da pek iyi değildi
      Sonunda yine baştaki duruma dönüyorsunuz

  • Burada çok faydalı geri bildirim var ama tıklama avcılığına kaçan bir ton da mevcut
    pnpm outdated konusunda bu ihtiyaç çok sık dillendirilmedi ama makul bir talep gibi görünüyor. Sanırım bu Python ve JavaScript kültürleri arasındaki farktan geliyor. Python bağımlılıkları savunmasız ya da kırık olmadıkça ne kadar eski olduklarını neredeyse hiç dert etmedim; ama JavaScript ekosisteminde fırsat buldukça yükseltme yapmak daha yaygın görünüyor. Bunun kötü olduğunu söylemiyorum, yalnızca büyük programlama toplulukları arasında komut satırı arayüzünde nelerin görünür olması gerektiğine dair sezgilerin ne kadar farklı olabildiğini gösteriyor
    Armin'in dediği gibi uv'nin üst sınır davranışı bilinçli ve Python'un çözümleme modeli açısından işlevsel olarak gerekli. Bu, Python'un diğer dillere kıyasla seçtiği bir ödün ama bağımlılık ağacında her bağımlılıktan yalnızca bir tane olması ve iç içe tüm gereksinimlerin buna göre çözülmesi açısından iyi bir ödün bence
    uv lock --upgradeın böyle davranmasının nedeni, kullanıcının kendi gereksinimlerini değil lock dosyasını yükseltmesidir. Buna karşılık pnpm update package.json içindeki kullanıcı gereksinimlerini güncelliyor gibi görünüyor. Kafa karıştırıcı olabilir ama bunu uv lock altında tutmak daha doğru. Aksi hâlde kullanıcılar uv upgrade komutunun kendi akıllarındaki yükseltmeyi yapmadığını düşünüp daha çok kafa karışıklığı yaşar. Yine de bunun daha temiz sunulması için alan var ve gereksinimlerin kendisini de doğrudan yükselten bir uv alt komutuna yönelik net kullanıcı talebi oldu
    https://news.ycombinator.com/item?id=48230048

    • Eski paketler ve üst sınırlar konusunda katılıyorum ama kullanıcılar arayüzün zor olduğunu söylüyorsa ortada gerçekten bir şey vardır
      uv lock komutunun sadece lock dosyasıyla ilgilenmesi mantıklı ama kullanıcıların doğrudan ve transitif bağımlılıkları yükseltme ihtiyacı gerçek. Transitif bağımlılıklar için uv lock --upgrade-package var ama biraz uzun. Doğrudan bağımlılıklarda da çalışıyor ama pyproject.toml dosyasına dokunmuyor; oysa geliştiricinin gözüne çok daha fazla çarpan dosya bu
      uv.lock içindeki paket sürümleri pyproject.tomlun önüne geçerse pyproject.toml, bağımlılık yüzeyini anlamaya yarayan bir rehber olarak daha az güvenilir hâle geliyor. Nazik bir uv upgrade komutu güzel olurdu
      Şimdiye kadar uv UX'inde gördüğüm en büyük tuzak uv pip. Birçok proje geliştirme için pyproject.toml ve uv.lock ile uv'yi doğru kullanırken dağıtım Dockerfile'larında ya da CI araçlarında uv pip install -r pyproject.toml kullanarak uv.lock dosyasını baypas ediyor
      Kodlama ajanlarının eğitim verilerinde çok fazla pip olduğu için kötü uv pip kalıpları önermesi bir sorun ama uv'nin de kullanıcıları koruyacak önlemler sunması gerekiyor
      uv harika bir araç ve daha yaygın kullanılmalı diye düşünüyorum: https://aleyan.com/blog/2026-why-arent-we-uv-yet
    • Yazar açısından “tıklama avcılığı” gibi göründüyse üzgünüm ama aslında bu sadece Hollanda usulü doğrudanlık ve dürüstlük
      poetry update de lock dosyasını güncelliyor. uv CLI'nın yapısını birlikte çalışması epey zahmetli buluyorum. Kullanıcı dostu olmaktan çok doğruluk ve makineler için tasarlanmış hissi veriyor
    • pip'ten uv'ye geçmiş biri olarak, o bilgiye ihtiyaç duyduğumda dönüp uv pip list --outdated kullanıyorum
    • uv upgrade yol haritasında var
      Henüz yapılmama nedeni, harika bir deneyim hâline getirmenin zor olması, konunun insanların beklediğinden çok daha fazla nüans içermesi, ekibin küçük olması ve önceliklerin fazla olması
    • pnpm outdated benzeri işlevlerin kullanım alanlarından biri "uv sync --update" ya da "uv lock --update" çalıştırıldığında nelerin güncelleneceğini önceden görmek
      Gerçi bu komutlara bir onay istemi eklemek daha iyi de olabilir

  • Pixi, arka planda uv kullanıyor ve eski paketleri okunaklı biçimde listeleyen görev takma adlarını kolayca ekleyebildiğiniz için arayüzünü sevdim
    Özellikle Pixi-diff-to-markdown, otomatik CI paket güncellemelerini gözden geçirmeyi kolaylaştırıyor
    Güncellenecek eski paketleri görmek istiyorsanız projeye şöyle bir görev takma adı ekleyebilirsiniz
    pixi task add outdated "pixi update --dry-run --json | pixi exec pixi-diff-to-markdown"
    Sonra projede pixi run outdated çalıştırmanız yeterli
    Çıktı; güncellenecek paketleri, mevcut sürümleri ve pixi update komutunun kuracağı yeni sürümleri içeren okunaklı bir Markdown tablo oluyor. Elbette zevk ve duruma göre değişebilir

  • Kısa süre önce env betiği PATH içinde görünmeye başladı ve normal UNIX env komutunun kullanımını bozdu
    Sonradan fark ettim ki uv yükleyicisi aşağıdaki komut çalıştırıldığında bunu oluşturuyormuş
    curl -LsSf [https://astral.sh/uv/install.sh](<https://astral.sh/uv/install.sh>;) | sh
    Bunu $HOME/.cargo/bin/ içine kuruyor ve $HOME/.cargo/bin/ PATH içinde yoksa başına ekleyen bir kabuk betiğini $HOME/.cargo/env olarak oluşturuyor
    Temel UNIX komutlarını bu şekilde gölgeleyen kodları bazı programcıların neden yazdığını anlamakta zorlanıyorum