YAML फ़ाइल क्या होती है?

YAML एक सादा टेक्स्ट फ़ॉर्मेट है, जो किसी भी एडिटर में खुल जाता है। इसका इस्तेमाल प्रोग्रामों के बीच डेटा ले जाना और एडिटिंग के लिए होता है।

एक्सटेंशन .yaml है और पूरा नाम YAML Ain't Markup Language। दोनों उतना नहीं बताते जितना यह कि फ़ाइल अंदर क्या-क्या रख सकती है — और इस पन्ने का बाक़ी हिस्सा इसी के बारे में है।

यह 2001 तक पीछे जाता है। विनिर्देश YAML 1.2 है।

उम्र एक व्यावहारिक वजह से काम की है: फ़ॉर्मेट जितना पुराना, उतने ज़्यादा प्रोग्रामों को उसे सीखने का वक़्त मिला है।

यह पूरा प्रकाशित है, इसलिए कोई भी इसे देखकर अंदाज़ा लगाने के बजाय दस्तावेज़ पढ़कर लागू कर सकता है। यही वजह है कि यह फ़ॉर्मेट इतने सारे प्रोग्रामों में मिलता है, और यही वजह है कि बीस साल पहले लिखी गई फ़ाइलें आज भी खुल जाती हैं। पर विनिर्देश का प्रकाशित होना और उसका रॉयल्टी-मुक्त होना एक बात नहीं है: जहाँ फ़ॉर्मेट किसी कोडेक को अपने अंदर लपेटता है, वहाँ पेटेंट का लाइसेंस एक अलग सवाल है, और मानक उसका जवाब नहीं देता।

YAML फ़ाइल अपना अंदरूनी हिस्सा हूबहू सहेजती है। दोबारा सहेजने से कुछ नहीं बदलता, इसलिए इसे जितनी बार चाहें खोलिए, बदलिए और फिर से सहेजिए — नुक़सान जमा नहीं होता। यही बात इसे सौंपने का नहीं, काम करने का फ़ॉर्मेट बनाती है।

YAML फ़ाइल में टिप्पणी लिखने का तरीक़ा मौजूद है — और यही उस फ़ाइल में, जिसे कोई इंसान सँभालता है, और उसमें, जिसे कोई प्रोग्राम लिखता है, फ़र्क़ करता है। बिना टिप्पणी वाले फ़ॉर्मेट में बदलते समय सबसे पहले यही जाती हैं, और चेतावनी कोई नहीं देता।

Visual Studio Code और yq इसे पढ़ते हैं, और इसी तरह के ज़्यादातर दूसरे प्रोग्राम भी।

फ़ाइल न खुले तो कसूर फ़ॉर्मेट का शायद ही कभी होता है — अक्सर प्रोग्राम ही फ़ॉर्मेट से पुराना होता है। किसी पुरानी चीज़ में बदल लेना इससे निकलने का भरोसेमंद रास्ता है, और इस वेबसाइट का बाक़ी हिस्सा इसी के लिए है।

इसे कोई भी ब्राउज़र नहीं पढ़ता।

इसे बदलने की सबसे आम वजह यही है: फ़ॉर्मेट ख़राब है, ऐसा नहीं — बात यह है कि जहाँ आप फ़ाइल दिखाना चाहते हैं वह जगह उसे पढ़ ही नहीं सकती।

YAML इसलिए बना है कि इसे खोला और बदला जाए। जब तक काम चल रहा है फ़ाइल इसी फ़ॉर्मेट में रखिए, और जब भी बनी हुई प्रति चाहिए हो, इसी से निर्यात कीजिए।

बहुत कम लोग YAML चुनते हैं। यह उन्हें सौंपा जाता है: Kubernetes मैनिफ़ेस्ट, GitHub Actions और GitLab CI पाइपलाइन, Ansible playbook, Docker Compose, OpenAPI विनिर्देश। इन सबने इसे तय किया, और इनके इर्द-गिर्द तंत्र इतने बड़े हैं कि फ़ॉर्मेट कोई फ़ैसला नहीं रहा।

इससे इसके बारे में काम का पन्ना कैसा दिखता है यह तय होता है। सवाल शायद ही कभी होता है YAML इस्तेमाल करें या नहीं — सवाल है इसके ग़लत होने के ख़ास तरीक़ों से कैसे बचें, क्योंकि यह आम इस्तेमाल के किसी भी और कॉन्फ़िगरेशन फ़ॉर्मेट से ज़्यादा चुपचाप असफल होता है।

कोई ब्रैकेट नहीं, कोई बंद करने वाला चिह्न नहीं। लाइन कितनी गहरी इंडेंट है यह तय करता है वह किसकी है, इसलिए ग़लत जगह पड़ा एक स्पेस दस्तावेज़ का मतलब बदल देता है — और अक्सर ऐसा दस्तावेज़ बनाता है जो अब भी मान्य है, बस आपके इरादे से अलग।

दो नियम ज़्यादातर रोकते हैं। कभी tab इस्तेमाल मत कीजिए: विनिर्देश इसे मना करता है। और इंडेंटेशन एक जैसा रखिए, रिवाज़ से प्रति स्तर दो स्पेस, क्योंकि एक फ़ाइल में अलग-अलग चौड़ाई मिलाना मान्य है और संरचना को एक नज़र में समझना नामुमकिन बना देता है।

YAML अंदाज़ा लगाता है कोई बिना-उद्धरण मूल्य क्या है, और अंदाज़ों ने असली आउटेज किए हैं। मशहूर है Norway problem: YAML 1.1 में, बिना-उद्धरण no बूलियन false है, इसलिए देश कोड की सूची में NO false बन जाता है। वही on, off, y और n के साथ होता है।

वर्शन संख्या दूसरी है: 1.20 फ़्लोट 1.2 बन जाता है। समय तीसरा है: 22:30 को स्ट्रिंग की जगह षष्टिक संख्या माना जा सकता है। बचाव है आदत, ज्ञान नहीं: पाठ के लिए इरादा किया कुछ भी उद्धृत कीजिए — वर्शन संख्या, देश कोड, पहचानकर्ता, समय।

YAML एक ब्लॉक एक बार परिभाषित कर सकता है और दोबारा इस्तेमाल कर सकता है। anchor उसे चिह्नित करता है, alias उसका संदर्भ लेता है, और merge key साझा ब्लॉक कई जगह जोड़ देता है — यही तरीक़ा है जिससे CI पाइपलाइन हर जॉब में वही छह लाइन दोहराने से बचती है।

यह सचमुच काम का है और यहीं YAML किसी नए के लिए पढ़ने लायक़ रहना बंद कर देता है। दो व्यावहारिक सावधानियाँ: alias कॉपी नहीं, संदर्भ है, इसलिए जो साझा है वह साझा है; और कई औज़ार जो YAML पढ़ते हैं anchor बिलकुल लागू नहीं करते।

खड़ी रेखा से लिखा block scalar लाइन-ब्रेक रखता है: स्क्रिप्ट, प्रमाणपत्र, पैराग्राफ़ वाले संदेश के लिए सही। greater-than चिह्न से लिखा हुआ लाइनों को एक में मोड़ देता है, जो पढ़ने के लिए लपेटे लंबे वाक्य के लिए सही है।

हर एक आख़िरी newline नियंत्रित करने वाला suffix लेता है — minus उसे हटाता है, plus हर पिछला रखता है। यह सुनने से कहीं ज़्यादा मायने रखता है जब मूल्य कोई key, token या स्क्रिप्ट हो: अनचाहा trailing newline प्रमाणपत्र ठुकराए जाने की क्लासिक वजह है।

अकेली लाइन पर तीन हाइफ़न नया दस्तावेज़ शुरू करते हैं, इसलिए एक फ़ाइल उनकी शृंखला रख सकती है। Kubernetes इसे लगातार इस्तेमाल करता है — एक फ़ाइल में deployment, service और config map।

यह जानना लायक़ है क्योंकि यह «इस फ़ाइल को पार्स करो» का मतलब बदल देता है। सिर्फ़ एक दस्तावेज़ पढ़ने वाला पार्सर पहले separator के बाद सब कुछ चुपचाप अनदेखा कर देता है, जो बिना एरर के आधा कॉन्फ़िगरेशन ग़ायब होने का तरीक़ा है।

हर JSON दस्तावेज़ मान्य YAML है, क्योंकि YAML 1.2 को उसका superset परिभाषित किया गया। तो JSON को YAML में बदलना मामूली और मुख्यतः सजावटी है — नतीजा वही डेटा है, पढ़ने में आसान और अब टिप्पणी ढो सकने वाला।

दूसरी दिशा वह चीज़ें खो देती है जिनके लिए JSON में जगह नहीं: टिप्पणियाँ, anchor, और बहु-पंक्ति स्ट्रिंग लिखने के कई तरीक़ों का फ़र्क़। इसलिए Kubernetes मैनिफ़ेस्ट को JSON से गुज़ारना उसकी हर व्याख्यात्मक टिप्पणी हटा देता है।

YAML मोड वाला एडिटर इस्तेमाल कीजिए। यह इंडेंटेशन गाइड दिखाएगा, tab बदलेगा, और संरचनात्मक ग़लती वहीं चिह्नित करेगा। रिपॉज़िटरी में जाने वाली किसी भी चीज़ के लिए, commit hook में linter लगाना दस मिनट के क़ाबिल है।

और भेजने से पहले मान्य कीजिए जब स्कीमा मौजूद हो। Kubernetes, OpenAPI और ज़्यादातर CI सिस्टम एक प्रकाशित करते हैं, और मान्यता जाँच वह ग़लत जगह पड़ी कुंजी पकड़ लेती है जिसे पार्सर ख़ुशी से स्वीकार कर लेता है।