Uv: dependencies वाले scripts चलाना

 (docs.astral.sh)
14 पॉइंट द्वारा GN⁺ 2025-07-22 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • uv का उपयोग करने पर Python script चलाते समय dependency management अपने-आप हो जाता है
  • अलग से virtual environment management किए बिना हर script के लिए environment अपने-आप बनता और बना रहता है
  • ज़रूरी package को inline metadata या command line option जैसी कई तरह की विधियों से घोषित किया जा सकता है
  • Python version और package management भी script स्तर पर घोषित और अपने-आप समायोजित किए जा सकते हैं
  • Lock file और dependency version constraint options से reproducibility और maintainability बेहतर होती है

परिचय

  • uv एक ऐसा tool है जो Python script चलाते समय उस script को चाहिए होने वाली package dependencies को अपने-आप manage करता है
  • उपयोगकर्ता को झंझट वाले virtual environment बनाना, package install करना जैसे काम खुद नहीं करने पड़ते
  • यह कई execution options, inline metadata का उपयोग, dependency declaration के अलग-अलग तरीके, और कई control features देता है

Python environment और uv की भूमिका

  • Python की हर installation का अपना अलग environment होता है
  • आम तौर पर virtual environment बनाकर उसे manage करना recommended है
  • uv virtual environment को अपने-आप manage करता है और dependencies को declarative तरीके से संभालता है
  • साधारण script को सिर्फ uv run example.py से तुरंत चलाया जा सकता है
  • अगर standard library का उपयोग हो रहा है, तो किसी अतिरिक्त setting के बिना काम करता है

Arguments पास करना और input के तरीके

  • script में command line arguments भेजे जा सकते हैं
  • standard input से सीधे script code लेकर चलाया जा सकता है, और here-document फीचर भी supported है

Project environment और --no-project option

  • अगर script project folder में चलाया जाता है, जैसे जहाँ pyproject.toml मौजूद हो, तो project dependencies भी install होती हैं
  • अगर इसकी ज़रूरत न हो, तो script नाम से पहले --no-project flag लगाकर project environment को ignore किया जा सकता है

Script dependencies की घोषणा और management

  • अगर external package चाहिए हों, तो command line option --with से dependencies बताकर script चलाया जा सकता है
  • specific version constraints भी supported हैं, और कई dependencies को option दोहराकर दिया जा सकता है
  • project environment में अतिरिक्त dependencies जोड़ी जा सकती हैं, और अगर यह नहीं चाहिए तो --no-project से control किया जा सकता है

Inline Script Metadata (PEP 723 तरीका)

  • Python अब script के भीतर ही dependencies या Python version घोषित करने के लिए एक standard format को support करता है
  • uv init --script से inline metadata वाला script आसानी से बनाया जा सकता है
  • uv add --script से script के लिए ज़रूरी dependencies को TOML format में जोड़कर manage किया जा सकता है
  • अगर inline metadata मौजूद हो, तो project dependencies को ignore किया जाता है और सिर्फ script dependencies लागू होती हैं

Python version की घोषणा और management

  • script के भीतर या execution के समय मनचाहा Python version बताया जा सकता है
  • अगर बताई गई version मौजूद न हो, तो उसे अपने-आप download और configure किया जाता है

Shebang से सीधे चलने वाले scripts लिखना

  • shebang(@#!...) का उपयोग करके uv run --script तरीके से सीधे executable file बनाई जा सकती है
  • इस स्थिति में भी dependency declaration और Python version जैसी चीज़ें script के शीर्ष पर लिखी जा सकती हैं

Package index और authentication support

  • --index option से custom package index इस्तेमाल किया जा सकता है
  • index की जानकारी metadata में भी शामिल की जा सकती है
  • अगर authentication की ज़रूरत हो, तो अलग documentation देखी जा सकती है

Dependency locking और reproducibility में सुधार

  • uv lock --script से script स्तर पर Lock file बनाई और manage की जा सकती है
  • इसके बाद execution या dependency जोड़ने के समय lock file दोबारा उपयोग होती है और ज़रूरत पड़ने पर update भी होती है
  • version reproducibility के लिए exclude-newer option दिया गया है, जो किसी तय तारीख के बाद की releases को बाहर रखता है
  • तारीख RFC 3339 timestamp के रूप में दी जाती है

Python version flexibility

  • हर execution के समय command line option से किसी भी Python version का उपयोग तय किया जा सकता है
  • उदाहरण: uv run --python 3.10 example.py

Windows support

  • .pyw extension वाले scripts Windows पर pythonw से चलाए जाते हैं
  • GUI आधारित scripts भी dependencies के साथ चलाए जा सकते हैं

संदर्भ दस्तावेज़

  • commands के ज़्यादा विस्तृत उपयोग के लिए CLI reference documentation और tool execution/install guide देखी जा सकती है

निष्कर्ष

  • uv एक ऐसा tool है जो Python scripts के execution environment, dependencies, versions, package index, और reproducibility को अपने-आप और आसानी से manage करके productivity और reliability दोनों बढ़ाता है

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

7 टिप्पणियां

 
ihabis02 2025-07-24

मैंने भी pip से uv पर स्विच करके देखा, और सच कहूँ तो सिर्फ इसकी वाकई तेज़ speed के लिए ही स्विच करना पूरी तरह बनता है।
 
idunno 2025-07-23

यह अक्सर ऊपर आता था, इसलिए मैंने इसे कल पहली बार इस्तेमाल किया... यह सच में बहुत तेज़ है। कमाल..
 
ytuniverse 2025-07-23

लगता है यहाँ सिर्फ़ uv से जुड़ी 5 से ज़्यादा पोस्टिंग्स देख चुका हूँ;;;
 
pmc7777 2025-07-23

दूसरी सुविधाओं को अलग रख दें, तो सिर्फ इसकी speed ही इसे इस्तेमाल करने की पर्याप्त वजह है.
अगर फिर से pip इस्तेमाल करने को कहें, तो अब वह बिल्कुल नहीं हो पाएगा.

मैं conda के system package management की जगह flake.nix इस्तेमाल कर रहा हूँ, और सहयोगी काम या उन मौजूदा projects को छोड़कर जो conda+pip पर maintain होते रहे हैं, व्यक्तिगत रूप से आगे मैं शायद uv+nix का इस्तेमाल करूँगा.
 
ndrgrd 2025-07-22

मैंने हाल ही में ज़्यादातर Python execution को uv से बदल दिया है, और यह सच में बहुत तेज़ है.
कुछ advanced features हैं जो पूरी तरह compatible नहीं हैं, लेकिन ज़्यादातर मामलों में यह लगभग एक जैसा ही काम करता है.
 
GN⁺ 2025-07-22
Hacker News की राय

  • "स्क्रिप्ट dependency declaration" फीचर सच में बहुत उपयोगी है
    आधिकारिक गाइड दस्तावेज़ में दिखाया गया है कि Python code के सबसे ऊपर comment के रूप में dependencies इस तरह लिखी जा सकती हैं

    # /// script
# dependencies = [
#  "requests<3",
#  "rich",
# ]
# ///
import requests, rich
# ... script

    इस फ़ाइल को script.py के रूप में सेव करने के बाद अगर "uv run script.py" से चलाएँ, तो घोषित dependencies जादू की तरह एक अस्थायी virtual environment में install हो जाती हैं और स्क्रिप्ट तुरंत चल सकती है
    यह Python के PEP 723 का implementation है, और Claude 4 भी इस ट्रिक को जानता है, इसलिए अगर उससे “inline script dependencies वाली Python script” लिखने को कहा जाए तो वह सही तरीके से बना देता है
    उदाहरण के लिए, httpx और click का उपयोग करके बड़ी फ़ाइल download करने और progress bar दिखाने वाला code लिखने को कहा जा सकता है
    Claude 4 से पहले ऐसी सुविधा के लिए custom project और अलग निर्देशों की ज़रूरत पड़ती थी, लेकिन अब ऐसा नहीं है
    विस्तृत उपयोग के उदाहरण भी देखे जा सकते हैं

    • shebang mode भी सच में बहुत उपयोगी है
      नीचे की तरह स्क्रिप्ट की पहली लाइन में shebang जोड़ दें, तो इसे ./script.sh की तरह चलाया जा सकता है

      #!/usr/bin/env -S uv run --script
# /// script
# dependencies = [
#  "requests<3",
#  "rich",
# ]
# ///
import requests, rich
# ... script

    • इच्छा है कि यह format requirements फ़ाइल जैसा होता
      अगर ऐसा होता, तो जिन users के पास uv नहीं है उनके लिए एक साधारण comment में pip से वही install करने वाला one-liner भी दिया जा सकता था
      उदाहरण के तौर पर pip install -r <(head myscript.py) जैसा तरीका संभव हो सकता है

    • वास्तव में PEP723 को आजकल चर्चा में रहने वाले uv के अलावा pipx और hatch भी support करते हैं
      और pip-tools आदि भी support roadmap में शामिल हैं
      (संबंधित issue देखें)

    • जब मैंने इसे पहली बार देखा था, तो एक पल के लिए requests के बगल में दिल वाला emoji समझ लिया था

    • मुझे यह तरीका सच में बहुत शानदार लगता है
      लेकिन उम्मीद है कि कभी न कभी यह magic comment की जगह built-in language syntax के रूप में अपनाया जाएगा
      comments थोड़े बेतरतीब लगते हैं
      बेशक tool के नज़रिए से magic comments को parse करना आसान है, और Python core में packaging knowledge सीमित होने जैसी संरचनात्मक बातें भी हैं, लेकिन फिर भी कभी built-in syntax आए तो अच्छा होगा

  • मैं इस तरीके से सहमत हूँ
    Python में requirements.txt अनिवार्य नहीं है, लेकिन अगर उसके रखरखाव में लापरवाही हो जाए तो चीज़ें टूटने की असुविधा अक्सर सामने आती है
    संबंधित ट्वीट देखें

  • मैं इस तरीके में झेला गया एक pitfall साझा करना चाहता हूँ
    मैंने इसे इंटरनेट बंद होने पर router restart करने वाली स्क्रिप्ट में इस्तेमाल किया था, लेकिन dependency installation खुद इंटरनेट कनेक्शन पर निर्भर होने की वजह से, नेटवर्क न होने पर स्क्रिप्ट ही नहीं चल पाती थी
    मैंने इसे पहले ही पकड़ लिया और dependencies को पहले से install करके हल कर लिया, लेकिन मेरी तरह गलती न करें और असली airgapped environment (जहाँ नेटवर्क पूरी तरह कटा हो) में इसका उपयोग न करने की सलाह दूँगा
    uv cache होने पर भी cache miss हो सकता है

    • uv run --offline option इस्तेमाल करने पर cached dependencies का उपयोग करके नया version check किए बिना चलाया जा सकता है
      यही सुविधा uvx में भी काम करती है (uvx --offline ...)

    • मेरी समझ में, अगर dependencies या venv का उपयोग करना है, तो कम से कम एक बार इंटरनेट कनेक्शन के साथ चलाना होगा, ताकि उसके बाद offline में भी इस्तेमाल किया जा सके

  • हाल के Python ecosystem में कई फीचर्स एक-दूसरे के साथ काफ़ी बेहतर तरीके से फिट होते दिख रहे हैं
    Marimo और uv script dependencies के संयोजन से, मैं दूसरी टीमों के उपयोग के लिए reproducible reporting/diagnostic tools बनाना शुरू कर रहा हूँ

  • uv का यही फीचर मुझे सबसे ज़्यादा पसंद आया और इसी वजह से मैंने uv अपनाया
    कई git-hooks scripts की अपनी-अपनी dependencies थीं, जिन्हें मैं main venv में install नहीं करना चाहता था
    #!/usr/bin/env -S uv run --script --python 3.13 की सिर्फ एक लाइन जोड़ने पर developers को बस brew install uv बताना काफी था, और अलग venv बनाए बिना स्क्रिप्ट के अंदर से ही सब इस्तेमाल हो जाता था

    • क्या किसी को पता है कि -S flag की ज़रूरत क्यों पड़ती है?
      मेरे BSD environment में /usr/bin/env -S uv run --python 3.11 python और /usr/bin/env uv run --python 3.11 python दोनों ही Python shell चलाते हैं, इसलिए नतीजा एक जैसा लगा
      env manual देखने पर भी यह साफ़ नहीं हुआ, इसलिए अगर किसी के पास उपयोगी जानकारी हो तो सुनना चाहूँगा
      (यहाँ -S arguments को spaces के आधार पर split करने का काम करता है)

    • UV की वजह से जो बड़ा Python migration काम मूल रूप से golang में करने का विचार था, उसका दायरा कम किया जा सका
      खासकर छोटे script-आधारित काम अब migrate करने की ज़रूरत नहीं रहे

    • मुझे पूरा भरोसा है कि यह सच में एक ‘killer feature’ है

  • अगर dependencies में Pytorch हो, तो यह तरीका थोड़ा सीमित हो सकता है
    Uv, Pytorch के लिए integrated support अच्छी तरह देता है, लेकिन सिर्फ script header से सबसे उपयुक्त wheel index (CPU, CUDA, ROCm आदि) को साफ़ तौर पर चुनने का तरीका न होना थोड़ा अफ़सोसजनक है

  • इच्छा है कि VS Code, uv द्वारा अपने-आप बनाए गए venv को आसानी से पहचान पाए
    अभी Python extension सभी third-party imports पर लाल रेखा दिखाता है
    फिलहाल अस्थायी उपाय के तौर पर uv की Cache directory से venv path मैन्युअली ढूँढकर register करना पड़ता है, लेकिन venv बार-बार recreate हो तो यह फिर दोहराना पड़ता है, जो काफ़ी झंझट वाला है

    • uv python find --script "${filePath}" कमांड से env path पाया जा सकता है
      उसी फीचर को VS Code में auto-detect करके activate करने वाला extension विकसित किया जा रहा है

  • UV का यह फीचर मुझे बहुत पसंद है
    jupyter notebook भी अलग से install किए बिना इस तरह एक line में चलाया जा सकता है

    uv run --with jupyter jupyter notebook

    सब कुछ एक अस्थायी virtual environment में install हो जाता है, और बाद में साफ़ कर दिया जाता है
    अगर इसे किसी project के अंदर चलाया जाए, तो उस project की dependencies भी अपने-आप पहचान ली जाती हैं

    • हालांकि यह पूरी तरह ‘साफ़’ नहीं होता, क्योंकि uv cache folder लगातार बड़ा हो सकता है

    • मैं भी uv run --with ipython --with boto3 ipython जैसे तरीकों से इसे अक्सर इस्तेमाल करता हूँ, और यह सच में बहुत समय बचाता है

  • हाल ही में uv run से जुड़ा एक छोटा issue मिला
    अगर script को project folder के बाहर से चलाएँ, तो यह असली script file location के बजाय current working directory में pyproject.toml खोजता है
    इसलिए जिन scripts की dependencies pyproject.toml में संग्रहीत हैं, वे “uv run path/to/my/script.py” की तरह बाहर से चलाने पर ठीक से काम नहीं कर सकतीं
    इस समस्या से हमेशा inline dependencies इस्तेमाल करके, या --project argument देकर निपटा जा सकता है, लेकिन तब script path दो बार लिखना पड़ता है, जो असुविधाजनक है
    uv कुल मिलाकर शानदार है, लेकिन यह छोटा सा व्यवहार काफ़ी परेशान करने वाला लगता है

  • मैं uv-विशेष shebang और in-script dependency वाले तरीके का संतोषजनक उपयोग कर रहा था
    इसके अलावा uv lock --script example.py कमांड से एक single script के लिए dedicated lock file भी बनाई जा सकती है, यह बात और भी प्रभावशाली लगी
    Python packaging को 20 साल से ज़्यादा हो गए, और इतनी स्वाभाविक experience का अब जाकर आना आश्चर्यजनक है

    • single script के लिए lock बनाने का use case जानने की जिज्ञासा है
      हमारे संगठन में lockfile dependencies को trivy fs uv.lock आदि से scan किया जाता है, ताकि ज्ञात CVE वाले code के चलने को रोका जा सके