uv और PEP 723 के साथ Python स्क्रिप्ट्स का उपयोग

 (cottongeeks.com)
14 पॉइंट द्वारा GN⁺ 2025-06-25 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • uv package manager और PEP 723 की मदद से dependency समस्याओं के बिना Python scripts चलाना संभव हो गया है
  • uvx फीचर disposable virtual environment अपने-आप बनाता है, जिससे environment setup की झंझट खत्म होती है
  • अगर PEP 723 metadata को Python फ़ाइल में शामिल किया जाए, तो script का automatic execution और package management काफी आसान हो जाता है
  • execution script example के रूप में YouTube subtitle extraction program को तेज़ी से implement और deploy किया जा सकता है
  • इससे अब Python में भी संक्षिप्त single-executable script लिखना संभव हो गया है, और scripts की उपयोगिता काफी बढ़ गई है

अवलोकन

  • Python में "one-off script" चलाने के लिए हर बार environment setup और package installation की प्रक्रिया से गुजरना पड़ता था, लेकिन uv और PEP 723 के आने से यह असुविधा लगभग खत्म हो गई है
  • uv, Rust में विकसित एक high-speed Python package और project manager है, और इसका नया uvx फीचर disposable virtual environment setup, automatic package installation, और Python version linking को बहुत तेज़ और आसान बनाता है

uv और uvx के फायदे

  • uvx फीचर Nodejs ecosystem के npx की तरह काम करता है और किसी निर्दिष्ट Python package (जैसे ruff) के लिए तेज़ी से execution environment तैयार करता है
  • disposable virtual environment को cache के रूप में इस्तेमाल करके बिना overhead के तेज़ execution देता है
  • environment setup और dependency installation एक ही command line में हो जाते हैं, इसलिए developer को अलग से environment management की ज़रूरत नहीं पड़ती

PEP 723 का परिचय और उपयोग

  • PEP 723 ऐसा standard define करता है जिससे Python script के शीर्ष पर dependency और environment metadata शामिल किया जा सके
  • उदाहरण: code के ऊपर requires-python, dependencies आदि को लिखा जा सकता है
  • इन जानकारियों को पहचानने वाले external tools (जैसे uv) script फ़ाइल में लिखी metadata के आधार पर automatic installation, environment setup, और execution संभाल लेते हैं

uv और PEP 723 का संयोजन

  • वास्तविक Python example file के शीर्ष पर यह metadata लिखने के बाद, uv के run command से execution करते ही ज़रूरी सभी packages अपने-आप install हो जाते हैं, तय Python version set हो जाता है, और फिर code चल जाता है
  • उदाहरण code internet API (PEP list) को call करता है और result को print करता है। अतिरिक्त package installation या environment setup के बिना इसे एक line में चलाया जा सकता है

व्यावहारिक उदाहरण: YouTube subtitle script

  • shebang(#!/usr/bin/env -S uv run --script) और PEP 723 metadata जोड़ी हुई Python script का उदाहरण दिया गया है
  • youtube-transcript-api जैसे external package अपने-आप install हो जाते हैं और virtual environment भी automatically set हो जाता है
  • user executable file(ytt) को चलाते समय YouTube video URL या ID argument के रूप में देता है, और script subtitles निकालकर तुरंत result दे देती है
  • chmod से execution permission देने के बाद इसे terminal में आसानी से चलाया जा सकता है

developer experience में सुधार और संभावनाओं का विस्तार

  • पहले साधारण script execution के लिए भी Go जैसी single-executable binary languages को अधिक पसंद किया जाता था, लेकिन अब Python भी लगभग उसी स्तर की सुविधा देता है
  • uv और PEP 723 के संयोजन से Python scripts को share करना, deploy करना, और उनका automated execution करना काफी आसान हो गया है
  • Github example (cottongeeks/ytt-mcp) के माध्यम से और भी जटिल use cases विकसित किए जा सकते हैं

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

2 टिप्पणियां

 
ndrgrd 2025-06-25

uv बहुत ही तेज़ है, इसलिए मुझे यह काफ़ी पसंद आया। आजकल मैं जहाँ भी संभव हो, हर जगह uv का इस्तेमाल कर रहा हूँ।
 
GN⁺ 2025-06-25
Hacker News राय

  • पोस्ट लिखने वाले की तरह आजकल मैं भी Go की बजाय cross-platform Python one-off और personal scripts की तरफ ज़्यादा झुकता हूँ, लेकिन Python का type checking system अभी भी पूरी तरह अराजक लगता है; उम्मीद है कि ty, pyrefly जैसे tools इससे थोड़ा सुधार लाएँगे

  • अब Python scripts ऐसा महसूस कराती हैं कि वे virtualenv की वजह से परेशान किए बिना सीधे ठीक से चल जाती हैं अच्छा होगा अगर shell scripts में भी ऐसा अनुभव मिल सके packaging, dependency management और reproducibility अभी भी पत्थर युग जैसी हालत में हैं अभी भी हक़ीक़त यही है कि या तो curl | bash के भरोसे किस्मत आज़माओ, या फिर ऐसा README मिले जिसमें 3 missing dependencies और 12 manual steps हों Nix? ऐसा विकल्प लगता है जो केवल उन्हीं के काम का है जो समय, स्थान और Nix manual—तीनों से परे जा चुके हों Docker? अगर सिर्फ़ एक sed command चलाने के लिए Linux distribution डाउनलोड करना आपको तर्कसंगत लगता है, तो ठीक है सच में एक आसान, declarative middle ground की ज़रूरत है जिसे हर कोई इस्तेमाल कर सके

    • मैं तो केवल ऐसी shell scripts लिखना पसंद करता हूँ जो target OS में पहले से मौजूद binaries और libraries ही इस्तेमाल करें shell scripts को portable बनाने का लक्ष्य व्यवहार में बहुत मेल नहीं खाता अगर आपको macOS-only commands वाली shell script Linux पर चलानी है, तो यह ऐसी समस्या है जिसे कोई package manager हल नहीं कर सकता
    • इस काम के लिए Nix उतना मुश्किल नहीं लगता दूसरी distributions पर Nix install करके इसे काफ़ी आसान तरीके से इस्तेमाल किया जा सकता है NixOS या पूरा Nix packaging ecosystem काफ़ी चुनौतीपूर्ण है, लेकिन सिर्फ़ shell scripts तक सीमित रखें तो entry barrier कम है
    • मुझे तो नई shell scripts लिखने की खास ज़रूरत महसूस नहीं होती अगर ऐसा environment है जहाँ सारी dependencies install करने की अनुमति हो, तो uv जैसा tool सब संभाल लेता है अगर आपको Clojure पसंद है, तो babashka भी सुझाऊँगा
    • shell script में packaging, dependency management और reproducibility का हाल पुराना इसलिए है क्योंकि जहाँ इनकी ज़रूरत पड़ती है, वहाँ shell शायद सही विकल्प ही नहीं है मेरा मानना है कि shell सिर्फ़ लगभग 20 lines तक की छोटी scripts के लिए ही ठीक है language की quality ही उससे बड़े scale के लिए पर्याप्त नहीं है
    • mise की सिफारिश हम कंपनी में development environment management के लिए इसका उपयोग करते हैं, और Docker या Nix की तुलना में environment setup बहुत आसान हो जाता है parallel installs का support सामान्य Dockerfile की तुलना में बड़ा फ़ायदा देता है

  • यह सच में शानदार trend है और लगता है कि धीरे-धीरे mainstream हो रहा है मैंने इसे पहली बार simonw के blog में देखा था, और simonwillison की blog post में इससे जुड़ी बातें देखीं इस साल मार्च में एक और blog post पर Hacker News चर्चा भी हुई थी अच्छा होगा अगर यह trend main page पर लंबे समय तक रहे ताकि ज़्यादा लोग इसके बारे में जानें

  • छोटे projects में uv इस्तेमाल करके अनुभव वाकई शानदार रहा uv run और uv tool run (uvx) के संयोजन से GitHub की Python scripts को VM पर सीधे install और run करना बेहद आसान हो जाता है न git clone की ज़रूरत, न venv बनाने या उसमें जाने की, न pip install की सबसे बढ़कर, uv इतना तेज़ है कि शुरुआत में लगा जैसे कुछ गड़बड़ है; असल में यह pip से 10 गुना तेज़ निकला हाँ, tool और documentation अभी थोड़ा अधूरा है, लेकिन इसकी innovation और practicality इतनी है कि फिर भी यह पूरी तरह उपयोगी है

    • सच में हैरानी होती है कि uv dependencies install करने का काम pyenv के --help output दिखाने से भी तेज़ कर देता है

  • Rust भी इसी तरह single-file typed shell script जैसी सोच को आगे बढ़ा रहा है मैंने इस तरह का approach पहली बार Rust में देखा था, जहाँ dependencies सहित single-file execution support मिलता है उम्मीद है यह pattern और भाषाओं में भी जमे, क्योंकि gist के रूप में आदान-प्रदान करने या छोटे तेज़ tools लिखने के लिए यह बहुत उपयोगी है cargo-script RFC document भी देख सकते हैं

  • uv run --script इस्तेमाल करते समय अगर metadata script में शामिल हो, तो script से सीधे Python REPL खोलकर edit-test करना थोड़ा असुविधाजनक है उदाहरण के लिए, ऐसा करना पड़ता है:

    $ uv run --python=3.13 --with-requirements <(uv export --script script.py) -- python
>>> from script import X

    काश इसका कोई और संक्षिप्त तरीका होता जैसे कि

    $ uv run --with-script script.py python

    ऐसा हो पाता तो सबसे अच्छा लगता, लेकिन वास्तव में नीचे दिए तरीके से script के अनुरूप Python और venv environment में सीधे प्रवेश किया जा सकता है

    $ "$(uv python find --script script.py)"
>>> from script import X

    हालाँकि environment बनाने के लिए script को कम से कम एक बार चलाना पड़ेगा

    • अगर setup के बाद REPL launch करने की सुविधा चाहिए, तो यह gist example देखना उपयोगी होगा script में --interactive जैसा flag जोड़कर इसे CLI option बनाया जा सकता है मैं अक्सर Typer आधारित छोटी CLI इसी तरह लिखता हूँ dev script में --sql flag से DuckDB SQL REPL में जाने का अनुभव भी रहा है
    • एक आसान तरीका यह है 
      cat ~/.local/bin/uve
#!/bin/bash
temp=$(mktemp)
uv export --script $1 --no-hashes > $temp
uv run --with-requirements $temp vim $1
unlink $temp

  • अगर आप conda इस्तेमाल करते हैं, तो Python script के लिए shell wrapper में environment को सीधे activate करने का तरीका भी है इसे इस तरह लिखा जा सकता है

    #!/usr/bin/env bash
eval "$(conda shell.bash hook)"
conda activate myenv
python myscript

    लेकिन यह PEP 723 style जितना self-contained approach नहीं है

  • कल और आज HN thread देखकर पहली बार uv आज़माने का फ़ैसला किया, और इसकी speed तथा आसान dependency management से बहुत प्रभावित हुआ अगर official docs और बेहतर हो जाएँ तो और अच्छा होगा, खासकर requirements.txt workflow से uv पर जाने की guide मिले तो सुविधा होगी project-specific Python version तय करने का हिस्सा थोड़ा confusing है (.python-version और pyproject.toml दोनों जगह definition)

    • मैंने Python developer tools explorer ebook लिखी है official docs जहाँ कमज़ोर लगते थे, वहाँ मैंने कुछ guidance दी थी: requirements.txt से migrate करने का तरीका और uv project का Python version बदलने का तरीका भी देख सकते हैं अगर और topics हैं जिन्हें cover किया जाना चाहिए, तो सुझाव हमेशा स्वागत योग्य हैं
    • pyproject.toml का requires-version field compatible versions की range बताता है, जबकि .python-version development के लिए उपयोग होने वाला specific version तय करता है uv init से शुरू में दोनों एक जैसे लग सकते हैं, लेकिन समय के साथ requires-version, .python-version की तुलना में कम minimum supported version दिखाने लगता है requires-version package metadata में भी जाता है, और आपके publish किए गए package का उपयोग करने वाले अन्य लोगों की dependency resolution को भी प्रभावित करता है उदाहरण के लिए, अगर v1 पुराने Python 3 versions को support करता हो लेकिन v2 नहीं
    • मुझे भी कुछ ऐसा ही लगता है, लेकिन मैं अपना workflow नहीं छोड़ता: वही files Dropbox से सभी computers में sync करके platform की परवाह किए बिना इस्तेमाल करता हूँ npm या dotnet की तरह platform बदलने पर npm update या dotnet restore चलाना पड़ सकता है, लेकिन venv आम तौर पर बिना दिक्कत चलता है जबकि uv में platform switch के समय चीज़ें थोड़ी ज़्यादा जटिल लगती हैं और manual cleanup की ज़रूरत महसूस होती है
    • pyproject.toml (खुद uv से अलग) बाहरी developers और users के साथ code share करने के लिए environment definition का काम करता है यानी PyPI package build करते समय किस environment की ज़रूरत है, यह बताना; version range भी इसलिए तय की जाती है ताकि दूसरे लोग code को ज़्यादा व्यापक रूप से reuse कर सकें .python-version सिर्फ़ uv के लिए है, और वह भी केवल मेरे development environment setup के संदर्भ में अगर environment पहले से बना हुआ है, तो इसे दोबारा सेट करने की ज़रूरत नहीं uv अभी official build backend नहीं है, लेकिन इस दिशा में काम चल रहा है (issue #3957)
    • मैंने विस्तार से नहीं देखा, लेकिन लगता है .python-version file का काम TOML parser न रखने वाले दूसरे tools के साथ compatibility भर है

  • पहले मैंने ऐसा tool बनाने की सोची थी जो Python scripts को खुद अपनी dependencies install करने दे (लक्ष्य uvx जैसा व्यवहार था, लेकिन ऐसा कि केवल Python होने पर भी चल सके) लेकिन कमी यह थी कि script की शुरुआत में कई अजीब दिखने वाली lines जोड़नी पड़ती थीं अगर जिज्ञासा हो, तो यह PyPI पर pysolate नाम से उपलब्ध है

    • इससे मिलता-जुलता लेकिन ज़्यादा प्रचलित नहीं isolate project भी है तरीका थोड़ा अलग है, लेकिन दिलचस्प approach है

  • COBOL से प्रेरित Grace Hopper style का संदेश तर्क यह है कि हर Python program में एक ENVIRONMENT division होनी चाहिए, जिसमें compile और execution environment—hardware और software requirements सहित—स्पष्ट रूप से लिखे जाएँ ऐसी संरचना अलग-अलग systems के बीच program portability सुधारने में निर्णायक हो सकती है