कोड formatting फीचर को प्रयोगात्मक रूप से uv में पेश किया गया

• नए uv वर्ज़न में code formatting फीचर को प्रयोगात्मक रूप से उपलब्ध कराया गया है
• uv format कमांड अंदरूनी रूप से Ruff formatter का उपयोग करके Python कोड को एकसमान style में फ़ॉर्मैट करता है
• अब अलग टूल के बिना सिर्फ uv से आसानी से कोड व्यवस्थित करना संभव है
• उपयोगकर्ता अतिरिक्त arguments के ज़रिए formatting behavior को विस्तार से नियंत्रित कर सकते हैं
• यह अभी प्रयोगात्मक फीचर है, इसलिए कमांड का तरीका, error handling आदि में बदलाव संभव है

---

अवलोकन

uv की नवीनतम रिलीज़ (0.8.13) में Python developers के लंबे समय से प्रतीक्षित प्रयोगात्मक कमांड uv format को पेश किया गया है। इस फीचर की मदद से प्रोजेक्ट के भीतर अलग formatting tool को मैनेज किए बिना सिर्फ uv के ज़रिए code style को व्यवस्थित किया जा सकता है

uv format क्या है?

• uv format कमांड uv interface के माध्यम से Python code formatting उपलब्ध कराता है
• अंदरूनी रूप से यह Ruff formatter को कॉल करके कोड को अपने-आप एकसमान ढंग से व्यवस्थित करता है

डेवलपर के लिए संदर्भ

Charlie Marsh (uv developer) ने Hacker News पर इसे इस तरह समझाया:

Ruff और uv का विलय नहीं हो रहा है, और दोनों अब भी अलग-अलग tools हैं
इसका उद्देश्य सिर्फ user experience बेहतर करना है ताकि उपयोगकर्ता formatter को अलग tool के रूप में महसूस किए बिना उसका उपयोग कर सकें
यह Rust ecosystem में cargo fmt और rustfmt के रिश्ते जैसा है

उपयोग का तरीका

• uv 0.8.13 या उससे ऊपर का वर्ज़न उपयोग करना होगा
• प्रोजेक्ट root में uv format कमांड चलाने पर ruff format चलाने जैसा प्रभाव मिलता है
• इसका execution तरीका uv के command interface का पालन करता है

अतिरिक्त arguments पास करना

• uv format -- [추가 인자] के रूप में Ruff को भेजे जाने वाले विस्तृत options सेट किए जा सकते हैं
• इससे uv की सुविधा और Ruff की बारीक settings, दोनों का एक साथ उपयोग किया जा सकता है

प्रयोगात्मक चरण की सूचना

• यह फीचर फिलहाल प्रयोगात्मक चरण में है, इसलिए आगे चलकर कमांड का तरीका या प्रोजेक्ट संरचना के साथ इसका integration बदल सकता है
• error handling, output format आदि में भी लगातार सुधार किया जाएगा
• उपयोगकर्ता feedback को शामिल करते हुए यह फीचर आगे विकसित होगा

निष्कर्ष

• अगर Python प्रोजेक्ट में सरल और एकसमान code styling की ज़रूरत है, तो uv format को सक्रिय रूप से आज़माया जा सकता है
• चूँकि यह प्रयोगात्मक शुरुआत है, इसलिए इसे इस्तेमाल करने के बाद feedback देना uv के आगे के विकास में योगदान दे सकता है

[GN⁺]

Hacker News की राय

• लगता है ruff को ty के साथ जोड़ना बेहतर होगा, और uv को package या project management पर ही केंद्रित रहना चाहिए; इसे code style editing तक नहीं जाना चाहिए। मेरे हिसाब से uv को code files केवल dependency updates (PEP 723) के समय ही बदलनी चाहिए
  • मैं यह स्पष्ट करना चाहता हूँ कि ruff और uv को merge नहीं किया जा रहा, और वे अलग tools ही बने रहेंगे। इसका उद्देश्य उन users के लिए एक सरल अनुभव देना है जो formatter के बारे में अलग से सोचना नहीं चाहते। यह Rust के Cargo जैसा सेटअप है, जहाँ cargo fmt अंदर से rustfmt चलाता है
  • यह Rust के cargo में cargo fmt होने वाली शैली की नकल है
  • मूल रूप से लक्ष्य uv को एक complete Python package manager बनाना है, जबकि उसके अलग-अलग component tools जरूरत पड़ने पर standalone भी इस्तेमाल किए जा सकें। यानी uv Python के लिए cargo जैसा है; अगर आपको सिर्फ तेज type checker चाहिए तो ty, और सिर्फ formatter/linter चाहिए तो ruff चुन सकें। इस लिहाज़ से ruff और ty को merge करना बहुत अर्थपूर्ण नहीं लगता
  • यह भी सोच रहा हूँ कि अगर कभी ty भी uv में शामिल हो जाए तो कैसा होगा। चूँकि ये सब astral.sh से आ रहे हैं, शायद यही vision हो, लेकिन अभी ty तैयार नहीं लगता
  • अगला तार्किक कदम शायद uv lint जैसा विकल्प जोड़ना होगा जो अंदर से ty चलाए। आदर्श रूप से एक standard command या commands की एक श्रृंखला से Python project को तैयार करना संभव होना चाहिए—format, lint, test, deploy—शायद यही यहाँ की vision है
• मैं uv का सच में आनंद लेकर उपयोग करता हूँ, लेकिन थोड़ी चिंता है कि यह अनावश्यक रूप से बड़ा होता जा रहा है। उदाहरण के लिए, कई subcommands बहुत सारे अनोखे flags support करते हैं, जिनमें से कुछ लगभग एक जैसे नतीजे देते हैं (uv run --no-project और uv run --active आदि)। बेवजह नए features जोड़ने के बजाय, काश वे मौजूदा tools और documentation सुधारने पर ज्यादा ध्यान दें
  • Python projects को stable, reproducible और portable बनाना सच में कठिन काम है। uv sync का सैद्धांतिक फायदा यह है कि वह reproducible package sets ही बनाता है, लेकिन torch-tensorrt या flash-attn जैसे जटिल packages environment के अनुसार बदल ही सकते हैं। Python community अक्सर समस्याओं को "मेरे कंप्यूटर पर तो काम करता है" कहकर व्यक्तिगत बना देती है, लेकिन software को deployable, secure, repeatable और reliable बनाने की लागत कभी गायब नहीं होती; बस बाद में किसी और को अधिक सीमित परिस्थितियों में वह कीमत चुकानी पड़ती है। इन विविध users और operational requirements को एक साथ संतुलित करना वास्तव में कठिन है
  • समझ नहीं आता कि uv में subcommands जोड़ना bloat क्यों माना जा रहा है। uv पहले से ही एक जटिल tool है और अच्छी तरह documented भी है। अगर commands इतने intuitive और self-explanatory हों, तो उनका जुड़ना काफी स्वाभाविक लगता है
  • uv के बारे में यह बहस कुछ वैसी लगती है जैसे कोई कहे, "make command में targets बहुत ज्यादा हैं"
  • जानना चाहूँगा कि ये options main executable में built-in होते हैं या apt और cargo की तरह अलग binaries के रूप में काम करते हैं
• मुझे लगता है यह update निश्चित रूप से सही फैसला है। समझ नहीं आता कि इतने लोग बेहतर दिशा का विरोध क्यों कर रहे हैं। हाँ, यह सही है कि "इसे थोड़ा ज्यादा असुविधाजनक तरीके से पहले से किया जा सकता है", लेकिन बात यही है कि वह 'थोड़ा ज्यादा असुविधाजनक' है
  • uvx ruff format का एक शब्द लंबा होना शायद कोई बुरी बात नहीं है। उल्टा, इससे यह अस्पष्ट हो सकता है कि वास्तव में कौन-सा formatter चल रहा है, क्या ruff अपने-आप install हो रहा है, या पहले की तरह tool download करके cache किया जा रहा है
  • इस बात से पूरी तरह सहमत हूँ। यहाँ तक कि अगर pyproject में formatter configure करने की सुविधा दे दें तो और भी अच्छा होगा
  • मेरी सबसे बड़ी शिकायत यह है कि फिलहाल किसी दूसरे formatter का support दिख नहीं रहा। अगर मेरे project में black इस्तेमाल होता है, तो uv format काम नहीं करेगा
• व्यक्तिगत रूप से, इस बदलाव से मेरी छोटी टीम (जिसमें actuarial professionals मुख्य सदस्य हैं) के लिए code formatting बहुत आसान हो जाएगी, इसलिए मैं इसे लेकर काफी उत्साहित हूँ। Python adoption और onboarding में uv का असर पहले ही काफी बड़ा रहा है, इसलिए code quality सुधारना आसान करने वाला कोई भी तरीका हमेशा स्वागतयोग्य है। हाँ, ruff को अलग से इस्तेमाल किया जा सकता है या pre-commit setup भी किया जा सकता है, लेकिन uv <feature> जैसा सरल mental model टीम के लिए बहुत मददगार है। अच्छा होगा अगर दूसरे formatters के साथ integration भी मिले, और अगर SQL/dbt model formatting तक support आ जाए तो और क्या चाहिए। अभी तो इसे आज़माकर इसकी संभावनाएँ देखना चाहता हूँ
  • अगर आपको सच में इतना multi-formatting चाहिए, तो शायद Makefile या justfile जैसी चीज़ बेहतर होगी। तब just format से Python/SQL/Bash/TypeScript सब कुछ एक साथ format किया जा सकता है
• यह थोड़ा feature overload जैसा लगता है। एक साल से ज्यादा समय से मैं uv का बढ़ता हुआ उपयोग कर रहा हूँ और इसके फायदे भी समझता हूँ, लेकिन यह अभी भी मेरी पहली पसंद नहीं है, और यह बदलाव शायद इसे मेरे लिए ज्यादा पसंदीदा नहीं बनाएगा
  • खास तौर पर जानना चाहूँगा कि इस तरीके में समस्या क्या है। Go, Rust और Elixir—तीनों यह तरीका अपनाते हैं, और इससे उन language ecosystems में project setup और usage काफी आसान हो जाता है। community एक साझा toolset पर केंद्रित हो पाती है, और beginners व experts दोनों के लिए एक consistent entry point मिलता है
  • अगर ऐसा है, तो जानना चाहूँगा कि आपकी सबसे पसंदीदा tool कौन-सी है
• लगता है कि किसी समय ruff की functionality uv और ty में integrate हो जाएगी। linting को ty संभाले तो वह codebase को बेहतर समझकर अधिक smart हो सकता है, और formatting को uv संभाले तो वह project management के अपने मुख्य उद्देश्य के अनुकूल होगा
  • ty पहले से ही ruff वाले repository में है, इसलिए integration भी शायद बहुत दूर की बात नहीं है
• package manager production environment के लिए packages install करने में आवश्यक है, लेकिन इसे केवल development tools के साथ मिलाना कुछ हद तक 'आकर्षक लेकिन खतरनाक जाल' जैसा लगता है। हाँ, Go और Rust भी ऐसा करते हैं, लेकिन मूल रूप से सोचें तो शायद यह बहुत अच्छी संरचना नहीं है
  • यह शायद बुरा लगे, लेकिन cargo काफी इस्तेमाल करने के बाद मेरी राय में ऐसे 'बुरे ideas' और होने चाहिए। अगर uv Python में cargo जैसी भूमिका निभा दे, तो Python development experience बहुत बेहतर हो जाएगा। 25 साल से अधिक समय तक Python इस्तेमाल करते हुए मैंने इसकी कई कमियों के आसपास रास्ते निकाले हैं; अब बिना ज्यादा सोचे सिर्फ uv से यह सब हो जाना बहुत संतोषजनक लगता है
• नया uv format असल में uv run --with ruff ruff का shortcut है
• मुझे यह दिशा सच में पसंद आ रही है। अगर मेरी चलती, तो इसका नाम uv fmt रखता, और roadmap में uv vet जैसी चीज़ भी जोड़ता
• पहले से ही कई साबितशुदा code formatter tools मौजूद हैं, इसलिए इसे लाने का कोई खास कारण महसूस नहीं होता। बस features बढ़े हुए लगते हैं, इसलिए फिलहाल इसे किसी pipeline में शामिल करने का इरादा नहीं है
  • uv format मूल रूप से ruff format का frontend ही है; कोई नया formatter नहीं जोड़ा जा रहा
  • अच्छा होगा अगर लोग यह समझें कि यह सिर्फ widely used ruff format को आसानी से चलाने के लिए एक shortcut भर है