uv शानदार है, लेकिन package management UX बुरी तरह अव्यवस्थित है

 (loopwerk.io)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • uv की ताकत इसकी तेज़ गति, Python version management, और single binary integration में है, लेकिन maintenance चरण में package management UX अभी भी काफी खुरदुरा है
  • पुराने पैकेज uv pip list --outdated से देखे जा सकते हैं, लेकिन यह top-level command नहीं है बल्कि pip-compatible namespace के भीतर है, इसलिए इसकी discoverability कम है
  • uv add pydantic डिफ़ॉल्ट रूप से pydantic>=2.13.4 जैसी बिना upper bound वाली constraint जोड़ता है, जिससे major version upgrade भी अनुमति पा जाते हैं
  • पूरा upgrade uv lock --upgrade से होता है, और कई specific packages के लिए --upgrade-package को बार-बार लिखना पड़ता है, जिससे command लंबी और बोझिल हो जाती है
  • add-bounds = "major" setting से ज़्यादा सुरक्षित default constraints दी जा सकती हैं, लेकिन यह preview feature है, और applications के लिए ज़्यादा intuitive update UX की ज़रूरत है

uv की ताकत और maintenance चरण की असुविधाएँ

  • Astral का uv तेज़ गति, Python version management, और कई tools को एक single binary से बदलने की क्षमता के कारण मज़बूत है
  • नया Python project शुरू करना और पहली dependency जोड़ना आसान है, लेकिन जब project maintenance phase में पहुँचता है, तब पुराने packages देखना और नियमित upgrade करना pnpm या Poetry की तुलना में अधिक खुरदुरा लगता है
  • मुख्य असुविधाएँ पुराने packages देखने वाले command की discoverability, default version constraints में upper bound की कमी, और upgrade commands की verbosity में हैं

पुराने packages देखना

  • JavaScript projects में pnpm outdated से पुराने packages, current version, latest version, और constraint के हिसाब से अनुमत version को संक्षेप में देखा जा सकता है
  • uv में top-level uv outdated command नहीं है, और शुरुआत में इसके बदले यह command इस्तेमाल की गई थी
$ uv tree --outdated --depth 1
  • uv tree --outdated --depth 1 सिर्फ पुराने items को filter नहीं करता, बल्कि पूरी top-level dependency tree दिखाता है और update किए जा सकने वाले items के पास छोटा annotation जोड़ता है
  • अगर dependencies 50 हों और पुराने packages सिर्फ 2 हों, तब भी 50 लाइनों की सूची देखनी पड़ती है
  • Poetry का poetry show --outdated command नाम के हिसाब से कम intuitive हो सकता है, लेकिन इसका output वास्तव में सिर्फ पुराने packages दिखाता है

default version constraints का जोखिम

  • pnpm और Poetry का default तरीका

    • pnpm add package.json में ^1.23.4 जैसी caret requirement लिखता है
    • ^1.23.4 1.x.x versions को अनुमति देता है, लेकिन 2.0.0 तक update नहीं करता
    • Poetry भी डिफ़ॉल्ट रूप से >=1.23.4,<2.0.0 जैसा format इस्तेमाल करता है; इसे पढ़ना थोड़ा कम आसान है, लेकिन असर वही है
    • इन दोनों tools में, अगर package SemVer का पालन करता है, तो pnpm update या poetry update चलाने पर मुख्य API changes की वजह से build टूटने की संभावना कम हो जाती है

  • uv का default तरीका

    • uv add pydantic pyproject.toml में इस तरह बिना upper bound वाली constraint जोड़ता है
dependencies = [
    "pydantic>=2.13.4",
]
  • इस constraint में pydantic 2, 3, 100 सभी versions अनुमत हैं
  • bulk update चलाने पर सिर्फ bug fixes ही नहीं, बल्कि dependency graph के सभी maintainers द्वारा जारी किए गए breaking changes भी आ सकते हैं
  • खासकर application maintenance में यह stability risk बन सकता है

upgrade command का UX

  • pnpm और Poetry में full update क्रमशः इतने सरल हैं
$ pnpm update
$ poetry update
  • uv में full upgrade के लिए यह command इस्तेमाल होती है
$ uv lock --upgrade
  • uv lock --upgrade, uv update या uv upgrade नहीं है, बल्कि lock command का एक option है, इसलिए human-facing package management command के रूप में यह कम intuitive लगता है
  • बिना upper bound वाली constraints के साथ मिलकर uv lock --upgrade lockfile के सभी packages को बिल्कुल latest versions तक ले जाने वाला विकल्प बन जाता है
  • इस update में वे deep nested dependencies भी शामिल हो सकती हैं जिनके बारे में direct जानकारी न हो
  • अगर सिर्फ कुछ specific packages update करने हों, तो pnpm में package names इस तरह सूचीबद्ध किए जा सकते हैं
$ pnpm update pydantic httpx uvicorn
  • uv में हर package के लिए --upgrade-package flag दोहराना पड़ता है
$ uv lock --upgrade-package pydantic --upgrade-package httpx --upgrade-package uvicorn
  • कई packages को एक साथ upgrade करते समय repeated flags बड़ी असुविधा बन जाते हैं

--bounds flag और settings

  • uv में हाल ही में uv add के लिए --bounds option जोड़ा गया है
$ uv add pydantic --bounds major
  • यह command ज़्यादा सुरक्षित constraint pydantic>=2.13.4,<3.0.0 बनाती है
  • --bounds major अभी preview feature है, और हर command पर manually opt-in करना पड़ता है
  • बाद में पता चला कि pyproject.toml में default value एक बार set की जा सकती है
[tool.uv]
add-bounds = "major"
  • इस setting के साथ हर बार --bounds major टाइप किए बिना आगे के uv add में ज़्यादा उचित default मिल सकते हैं
  • applications में यह व्यवहार default होना बेहतर होगा, लेकिन वास्तविक usability पहले बताए गए स्तर जितनी बुरी नहीं है

applications और libraries का अंतर

  • Python packaging की standard सलाह यह है कि PyPI पर प्रकाशित libraries upper bounds को pin न करें, और यह सलाह उचित है
  • अगर सभी libraries upper bounds pin कर दें, तो downstream users की dependency tree resolve न हो पाने की समस्या आ सकती है
  • इसके उलट applications dependency graph के अंतिम node होते हैं, और अन्य users उनकी constraints के आधार पर resolution नहीं करते
  • applications में upper bounds रखने की कोई खास लागत नहीं होती, और यह अनपेक्षित major version upgrades से सुरक्षा दे सकता है
  • यहाँ संदर्भ website, service, internal tool जैसी applications के maintenance का है; library distribution में बिना upper bound वाला default उचित हो सकता है

सुधरे हुए हिस्से और बची हुई समस्याएँ

  • uv pip list --outdated का उपयोग करने पर सिर्फ पुराने packages को filter करके देखा जा सकता है
$ uv pip list --outdated
  • इससे uv tree --outdated --depth 1 के शोरगुल वाले output पर की गई आलोचना कुछ कमज़ोर पड़ती है
  • बची हुई समस्या यह है कि यह feature top-level command नहीं है, बल्कि pip-compatible namespace के भीतर है, इसलिए इसकी discoverability कम है
  • add-bounds = "major" setting से default bounds तय किए जा सकते हैं, इसलिए हर बार upper bound manually edit करने या risk लेने वाला द्वंद्व पूरी तरह सही नहीं है
  • फिर भी यह feature preview में है, और application package management में ज़्यादा सुरक्षित default constraints और ज़्यादा intuitive update commands की ज़रूरत बनी हुई है

अपेक्षित सुधार की दिशा

  • सिर्फ पुराने packages को साफ़ तौर पर दिखाने वाला एक dedicated uv outdated command होना चाहिए
  • कई packages update करते समय flags दोहराने की आवश्यकता न हो, ऐसा ज़्यादा ergonomic update command होना चाहिए
  • default version constraints को semantic versioning (SemVer) से जुड़ी stability expectations को बेहतर ढंग से दर्शाना चाहिए
  • वर्तमान स्थिति में lockfile के हर बदले हुए line को शक की नज़र से जाँचने का बोझ बना रहता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • uv add की डिफ़ॉल्ट version range को स्थायी setting के रूप में सेट किया जा सकता है, इसलिए हर बार पास करने की ज़रूरत नहीं होती
    संदर्भ: https://docs.astral.sh/uv/reference/settings/#add-bounds
    डिफ़ॉल्ट रूप से upper bound न रखने की वजह यह है कि इससे ecosystem में बहुत से अनावश्यक conflict बनते हैं, और Poetry इस्तेमाल करने के समय इस विषय पर सामग्री भी इकट्ठा की गई थी: https://github.com/zanieb/poetry-relax#references

    • लाइब्रेरी distribute करते समय upper version हटाना महत्वपूर्ण है, यह बात समझ में आती है, लेकिन यह लेख लाइब्रेरी नहीं बल्कि वेबसाइट बनाने के नज़रिए से लिखा गया है
      वेब प्रोजेक्ट में dependency इस्तेमाल करते समय, dependency के SemVer मानने की धारणा पर breaking change रोकने के लिए upper bound होना बेहतर लगता है
    • Haskell community भी इस समस्या से कई साल जूझती रही, और एक समय सबसे सफल तरीका Stackage था
      इसने defensive upper bounds न जोड़ने के लिए प्रोत्साहित किया, ecosystem के बड़े सक्रिय हिस्से को हर release पर लगातार build करके वास्तविक compatibility issues ढूँढे, owners को automatic notification भेजे, और अगले "LTS" release में बने रहने के लिए स्पष्ट timeline दी
      अब सिर्फ Cabal solver से भी चीज़ें काफ़ी stable लगती हैं, लेकिन बड़े पैमाने पर nightly builds और दिखने वाली failures/blockers ने ecosystem को solvable बनाए रखने में ज़रूर मदद की होगी
    • add-bounds setting के बारे में अभी पता चला, और exact dependency pinning महत्वपूर्ण है, लेकिन यह उन projects, खासकर लाइब्रेरी नहीं बल्कि final product वाले projects, के लिए उपयोगी है जिन्हें कम अनुभवी developers आसानी से मिस कर सकते हैं
    • जानना चाहता हूँ कि --native-tls flag को स्थायी रूप से सेट करने का कोई तरीका है या नहीं
      दफ़्तर के Zscaler setup की वजह से इस flag के बिना UV हमेशा fail हो जाता है
      साथ ही यह भी जानना चाहता हूँ कि क्या किसी विशेष architecture के लिए compatible Python version तय करने की सुविधा आने वाली है। कंपनी में maintain किए जाने वाले एक package को 32-bit Python चाहिए, इसलिए हमेशा --python /path/to/32bit देना पड़ता है
    • सवाल थोड़ा कम polished हो सकता है, लेकिन जानना चाहता हूँ कि क्या uv को pyproject.toml के exclude-newer का सम्मान कराने का कोई तरीका है
      uv run चलाने पर pyproject.toml से exclude-newer हट जाता है
      हर बार uv run —-frozen या uv run --exclude-newer चला सकता हूँ, लेकिन यह सही flow जैसा नहीं लगता; शायद कोई idiomatic तरीका हो जो मैं मिस कर रहा हूँ

  • uv को एक single resolution result चाहिए, इसलिए upper bound न होना जानबूझकर किया गया design है
    npm tree के अलग-अलग हिस्सों में अलग resolution install कर सकता है, लेकिन Python में वह विकल्प नहीं है। Rye में भी यही निर्णय लेना पड़ा था, और इसका कोई बेहतर हल नहीं है
    upper bound लगाने से वास्तव में ऐसा tree बन सकता है जिसे solve ही न किया जा सके। Python package ecosystem के कुछ हिस्सों ने अतीत में गलत upper bounds के साथ publish हुए पुराने packages के लिए override तक publish किए थे
    आज की तारीख में यह जानना संभव नहीं कि कोई अभी तक release न हुआ package आपकी package के साथ compatible होगा या नहीं

    • व्यक्तिगत रूप से मुझे यह बेहतर लगता है कि update करते समय incompatible packages की error uv से मिले और ज़रूरत हो तो override किया जा सके
      यह runtime पर मिलने वाली, version incompatibility की ऐसी error से बेहतर है जिसे trace करना मुश्किल हो
    • असली समस्या pyproject.toml में upper bound न होना नहीं है
      असली समस्या यह है कि uv lock —-upgrade upper bound न रखने वाली हर चीज़ को एक साथ upgrade कर देता है
      अगर major version बढ़ाए बिना package upgrade करने का कोई तरीका हो, तो यह command कहीं ज़्यादा सुरक्षित हो जाएगी
    • uv ने हालात बहुत बेहतर किए हैं, लेकिन मूल रूप से लगता है कि कुछ चीज़ें ऐसी हैं जिन्हें सिर्फ tool से हल नहीं किया जा सकता
      uv से पहले की तुलना में बहुत बड़ा सुधार है, लेकिन पूरे ecosystem में कुछ breaking changes किए बिना इसे पूरी तरह बेहतर बनाना मुश्किल दिखता है। Python 2 से 3 के बदलाव को देखें तो फिलहाल ऐसे बदलाव की इच्छा भी ज़्यादा नहीं लगती
    • लाइब्रेरी लेखक के लिए यह बात सही है, लेकिन वेबसाइट बनाते समय और कई packages पर निर्भर होने पर upgrade के दौरान सुरक्षित रहने के लिए upper bounds चाहिए
      —-bound flag मददगार है, लेकिन टाइप और याद रखने के लिए यह एक और चीज़ बढ़ा देता है
      अगर uv यह समझ सके कि यह project लाइब्रेरी नहीं है, तो शायद डिफ़ॉल्ट रूप से upper bounds जोड़ना संभव हो
    • सच कहें तो uv हो या npm, सही तरीका यही है कि सब कुछ = में बदलो, non-major updates पर भी भरोसा मत करो कि वे break नहीं करेंगे, और सिर्फ manually update करो

  • production में चल रहे app में 257 Python dependencies हैं, जिनमें आधे से ज़्यादा direct dependencies हैं
    pyproject.toml में upper bounds नहीं हैं, और हर दो हफ़्ते में GitHub Actions से uv lock --upgrade चलाया जाता है
    test coverage अच्छी है, इसलिए कुछ टूटे तो tests fail हो जाते हैं, और AI-assisted review flow भी है। upgrade PR बनते ही AI workflow Python script के ज़रिए major/minor version updates की सूची बनाता है, changelog ढूँढकर link और summary देता है, और codebase में package कैसे उपयोग हो रहा है इसके आधार पर हर package का risk analyze करता है
    कुल मिलाकर बहुत कम दर्द होता है, और packages को एक-एक करके बढ़ाने, पुराने packages देखने या छोड़ी हुई dependencies सँभालने की ज़रूरत नहीं पड़ती। ऐसा बहुत कम होता है कि dependency author की तरफ़ से fix चाहिए और code में हल न हो सके; लगभग साल में एक बार। पिछले 3 महीनों में 18 major version bumps हुए, जिनमें सिर्फ एक में code change की ज़रूरत पड़ी
    frontend में भी ऐसा करना चाहता हूँ, लेकिन इसे सुरक्षित रूप से चलाने लायक tests पर्याप्त नहीं हैं। backend tests लिखना आसान है और ज़्यादा महत्वपूर्ण भी, इसलिए मेरा मानना है कि हर codebase में यह होना चाहिए। अगर tests हों, तो बस सब कुछ auto-upgrade किया जा सकता है

    • tests लिखना AI agents के लिए भी बहुत अच्छा काम है
      कम से कम natural language निर्देशों को सटीक tests में बदलने में वे बेहतरीन हैं
      काफ़ी समय से tests हाथ से नहीं लिखे, जबकि पहले यह हमेशा शिकायत की चीज़ हुआ करती थी, अब नहीं

  • UV ने Python के लिए बहुत कुछ किया है, लेकिन आज इससे काफ़ी जूझना पड़ा
    अलग-अलग repositories में बिखरी और समय के साथ अलग-अलग तरह से implement हुई scripts को centrally manage करने की कोशिश कर रहा था
    सोचा गया तरीका uv run --with $package main --help था, और चाहत यह थी कि अपने-आप 1) installed न हो तो install करके run करे, 2) latest हो तो install न करे, 3) latest न हो तो update करे
    लेकिन तीनों चीज़ें उम्मीद से ज़्यादा मुश्किल निकलीं। मूल रूप से uv run हर बार फिर से install कर रहा था, और virtual environment व installation में 6 सेकंड लग रहे थे
    uvx या uv tool भी बहुत बेहतर नहीं थे, क्योंकि वहाँ नई समस्या यह थी कि users को upgrades नहीं मिल रहे थे
    आख़िर में script को CodeArtifact पर pagination GET request भेजकर नया non-dev version हो तो update करने और फिर rerun करने के लिए बनाया। यह काम करता है, और 6 सेकंड से 200ms delay बेहतर है, लेकिन अनुभव वैसा नहीं था जैसा चाहिए था

    • uv run --with $package main --help को आपकी बताई हुई behavior बहुत कम overhead के साथ करनी चाहिए, इसलिए यह थोड़ा उलझाने वाला है
      यह हर बार reinstall नहीं करता; --with environment cache में रखी जाती है और बनी रहती है। environment cache न भी हो, तो dependencies cache हो जाती हैं, और cache से install बहुत तेज़ होना चाहिए। निश्चित रूप से 200ms से कम होना चाहिए
      अगर आप detailed reproduction example खोलें तो इसे देखा जा सकता है
    • उस use case के लिए uv tool install और uv tool upgrade सही लगते हैं
      हालाँकि इस तरह की छोटी असुविधाएँ अपेक्षाकृत आसानी से हल हो सकती हैं, इसलिए issue खोलना अच्छा रहेगा
    • file के सबसे ऊपर document block में ज़रूरी dependencies define करके फिर सिर्फ uv run main भी चलाया जा सकता है
      तब यह ज़रूरी dependencies automatically install, cache और run करेगा: https://docs.astral.sh/uv/guides/scripts/
    • क्या user बस uv tool upgrade नहीं चला सकता?
    • https://copier.readthedocs.io/en/stable/ भी देखने लायक है
      ठीक यही use case है या नहीं, पता नहीं, लेकिन polyrepo microservice ecosystem को sync में रखने के लिए यह बहुत अच्छा रहा

  • पुरानी dependencies की सूची देखने के लिए "uv tree --outdated --depth 1" की सिफारिश देखना काफ़ी चौंकाने वाला था
    व्यक्तिगत रूप से मैं इसके आने के बाद से "uv pip list --outdated" इस्तेमाल करता रहा हूँ
    फिर भी मैं सहमत हूँ कि इतना महत्वपूर्ण command अलग top-level subcommand का हकदार है

    • लेखक के नज़रिए से वह recommendation कम और उनकी जानकारी का एकमात्र तरीका ज़्यादा था
      "uv pip list --outdated" वाकई कहीं बेहतर output देता है, धन्यवाद
      लेकिन पुरानी packages देखने के दो तरीके होना और दोनों के output का बहुत अलग होना भी UX को खराब बताने का कारण लगता है
    • "uv tree -od1" भी शायद काम करेगा
      लेकिन pacman जैसे package managers की आलोचना में भी यही बात थी कि apt की तरह अक्सर इस्तेमाल होने वाले commands के लिए इंसान को समझ आने वाले command names देने चाहिए

  • शीर्षक में “mess” जैसी अभिव्यक्ति की तुलना में, उदाहरण तो बस कुछ extra arguments लिखने की बात हैं
    बेहतर शीर्षक शायद UV में जिन quality-of-life सुधारों की इच्छा है जैसा होता

    • वह अभिव्यक्ति और “इस command line interface को किसने design किया?” जैसी पंक्तियाँ ध्यान और clicks के लिए लिखी हुई लगती हैं
      feedback खुद उपयोगी है और ज्यादातर बातों से सहमति है, लेकिन ऐसी भाषा feedback की value घटाती है और defensive reactions बुलाती है
      uv का command line interface मुझे भी व्यक्तिगत रूप से awkward लगता है, लेकिन यह इस तरह क्यों लिखा गया, यह समझ में आता है

  • uv शानदार है, लेकिन मौजूदा Python packaging की सबसे बड़ी समस्या अब भी scientific/machine learning packaging को सही ढंग से संभालना है
    अगर PyTorch install करना है, तो पहले यह देखना पड़ता है कि कौन सा version चाहिए, CUDA चाहिए या नहीं। CUDA चाहिए तो CUDA version के हिसाब से 6 तरह के versions हैं, और wheels इतने बड़े हैं कि उन्हें PyPI पर डालना मुश्किल है, इसलिए अलग से लेना पड़ता है
    Conda इस समस्या को सिर्फ आंशिक रूप से हल करता है। Spack बेहद configurable है और ज़रूरी C/C++/Fortran dependencies तथा compiler toolchain तक उपलब्ध करा सकता है, इसलिए सर्वोत्तम performance निकालने के लिए बेहतरीन है, लेकिन uv आदि के साथ अच्छी तरह integrate नहीं होता। इसलिए researchers द्वारा बनाए गए experimental machine learning projects को production तक ले जाना मुश्किल हो जाता है

    • पहले Anaconda से इस समस्या को bypass किया था, लेकिन उसके साथ बहुत सारा extra सामान आता था और development environment, production environment से बिल्कुल अलग हो जाता था, इसलिए वह भी अच्छा नहीं लगा
      आख़िरकार फिर वही पहले बताई गई स्थिति लौट आती है

  • इसमें काफ़ी उपयोगी feedback है, लेकिन clickbait जैसी भाषा भी मिली हुई है
    pnpm outdated के बारे में यह बात अब तक ज़्यादा सामने नहीं आई, लेकिन यह एक reasonable मांग लगती है। शायद यह Python और JavaScript संस्कृति के अंतर से आता है। Python dependencies vulnerable या broken न हों तो वे outdated हैं या नहीं, इस पर मैंने लगभग कभी ध्यान नहीं दिया, लेकिन JavaScript ecosystem में मौका मिले तो upgrade करना काफ़ी आम लगता है। यह बुरी बात नहीं है, बल्कि यह दिखाता है कि बड़े programming communities के बीच command line interface में क्या surface किया जाना चाहिए, इस बारे में intuition कितनी अलग हो सकती है
    जैसा Armin ने कहा, uv का upper bounds वाला behavior जानबूझकर है, और Python resolution model के हिसाब से यह functional necessity है। यह Python का दूसरे languages की तुलना में चुना गया trade-off है, लेकिन dependency tree में हर dependency की केवल एक copy होने और उससे जुड़ी सभी requirements का उसी पर resolve होना, मेरे हिसाब से अच्छा trade-off है
    uv lock --upgrade ऐसा इसलिए है क्योंकि यह user requirements नहीं बल्कि lock file को upgrade करता है। इसके विपरीत pnpm update शायद package.json में user requirements को update करता है। इससे भ्रम हो सकता है, लेकिन इसे uv lock के तहत रखना ज़्यादा सही है। वरना uv upgrade नाम देखकर users उलझेंगे कि यह उनके हिसाब का upgrade क्यों नहीं कर रहा। फिर भी इसे और साफ़ तरीके से पेश करने की गुंजाइश है, और requirements को सीधे upgrade करने वाले uv subcommand की user demand स्पष्ट रूप से रही है
    https://news.ycombinator.com/item?id=48230048

    • outdated packages और upper bounds पर सहमति है, लेकिन अगर users interface को कठिन कह रहे हैं, तो निश्चित ही कुछ बात है
      uv lock command सिर्फ lock file को संभालता है, यह समझ में आता है, लेकिन users को direct और transitive dependencies upgrade करने की वास्तविक ज़रूरत होती है। transitive dependencies uv lock --upgrade-package से हो सकती हैं, लेकिन यह थोड़ा verbose है। direct dependencies पर भी यह काम करता है, लेकिन pyproject.toml को नहीं छूता, जबकि developers के लिए वही file कहीं ज़्यादा नज़र में रहती है
      अगर uv.lock में package versions pyproject.toml से आगे निकल जाएँ, तो pyproject.toml dependency surface समझने के guide के रूप में कम भरोसेमंद हो जाता है। एक friendly uv upgrade command अच्छा रहेगा
      अब तक देखे गए uv UX का सबसे बड़ा trap uv pip है। बहुत से projects development में pyproject.toml और uv.lock के साथ uv का सही उपयोग करते हैं, लेकिन deployment Dockerfile या CI tooling में uv pip install -r pyproject.toml लिखकर uv.lock को bypass कर देते हैं
      coding agents भी training data में pip बहुत ज़्यादा होने की वजह से खराब uv pip patterns सुझाते हैं, यह भी समस्या है, लेकिन uv को भी users की सुरक्षा के लिए guardrails देने चाहिए
      uv शानदार tool है और इसका ज़्यादा उपयोग होना चाहिए: https://aleyan.com/blog/2026-why-arent-we-uv-yet
    • लेखक के नज़रिए से, अगर यह “clickbait” लगा हो तो खेद है, लेकिन वास्तव में यह बस डच शैली की सीधापन और ईमानदारी है
      poetry update भी lock file update करता है। uv CLI का संगठन मुझे काम करने में काफ़ी परेशान करने वाला लगता है। ऐसा महसूस होता है कि इसे correctness और machines के लिए design किया गया है, user-friendliness के लिए नहीं
    • pip से uv पर आए लोगों के लिए, जब वह जानकारी चाहिए होती है तो वे uv pip list --outdated पर वापस चले जाते हैं
    • uv upgrade roadmap पर है
      अभी तक नहीं हुआ क्योंकि इसे शानदार अनुभव बनाना मुश्किल है, इसमें लोगों की अपेक्षा से कहीं ज़्यादा nuance है, और टीम छोटी है जबकि priorities बहुत हैं
    • pnpm outdated जैसे feature का एक उपयोग यह देखना है कि "uv sync --update" या "uv lock --update" चलाने पर क्या update होगा
      हालाँकि शायद उन commands में confirmation prompt देना बेहतर हो सकता है

  • Pixi, uv को backend के रूप में इस्तेमाल करता है, और outdated packages को अच्छे ढंग से list करने वाला task alias आसानी से जोड़ने देता है, इसलिए उसका UI पसंद आया
    खासकर Pixi-diff-to-markdown automatic CI package updates को जल्दी समझने में मदद करता है
    अगर आप outdated packages में से यह देखना चाहते हैं कि क्या update होगा, तो project में ऐसा task alias बनाया जा सकता है
    pixi task add outdated "pixi update --dry-run --json | pixi exec pixi-diff-to-markdown"
    और फिर project में pixi run outdated चलाइए
    output एक पढ़ने में आसान Markdown table होता है जिसमें update होने वाले packages, पुराना version, और pixi update command से install होने वाला नया version दिखता है। बेशक, यह पसंद और परिस्थिति पर निर्भर कर सकता है

  • हाल ही में env script path में आ गई और सामान्य UNIX env command के उपयोग में बाधा डालने लगी
    बाद में पता चला कि uv installer नीचे वाला command चलाने पर इसे बनाता है
    curl -LsSf [https://astral.sh/uv/install.sh](<https://astral.sh/uv/install.sh>;) | sh
    यह $HOME/.cargo/bin/ में install करता है, और $HOME/.cargo/env में shell script बनाता है जो $HOME/.cargo/bin/ अगर PATH में न हो तो उसे आगे जोड़ देती है
    यह समझना मुश्किल है कि कौन से programmers ऐसा code लिखते हैं जो इस तरह बुनियादी UNIX commands को overwrite कर दे