TOML से YAML

TOML और YAML के बीच क्यों जाना है

दोनों प्रारूप मनुष्य-संपादित कॉन्फ़िगरेशन फ़ाइलों को लक्ष्य करते हैं, लेकिन उनके आसपास का पारिस्थितिकी तंत्र अलग है। TOML Python पैकेजिंग (pyproject.toml), Rust (Cargo.toml), GitHub वर्कफ़्लोज़ और कई CLI टूल्स का मानक है। YAML Kubernetes, Ansible, Docker Compose, GitHub Actions (पुरानी सिंटैक्स), और कई CI सिस्टम्स का मानक है।

कभी-कभी आपको एक ही कॉन्फ़िगरेशन को दोनों प्रारूपों में व्यक्त करने की ज़रूरत होती है: किसी Ansible प्लेबुक के अंदर pyproject.toml का एक स्निपेट फिर से उपयोग करना, या किसी Kubernetes ConfigMap को Cargo.toml निर्भरता ब्लॉक में उतारना। एक TOML-से-YAML कन्वर्टर अनुवाद को यांत्रिक रखता है।

रूपांतरण से क्या बच जाता है

मैपिंग्स, सीक्वेंसेस, स्केलर्स (स्ट्रिंग्स, इंटीजर्स, फ़्लोट्स, बूलियन, ISO तारीख़ें), इनलाइन टेबल्स, और डॉटेड कुंजियाँ सभी स्वच्छ रूप से अनुवादित होती हैं। मल्टी-लाइन स्ट्रिंग्स को YAML ब्लॉक स्केलर्स के रूप में उत्सर्जित किया जाता है, जो मूल TOML लेखक द्वारा चुनी गई दृश्य लेआउट को संरक्षित करता है।

क्या नहीं बचता

YAML टैग (!!str, !!int, आदि) केवल तब उत्सर्जित होते हैं जब अंतर्निहित प्रकार YAML की डिफ़ॉल्ट अनुमान से भिन्न हो। व्यवहार में पार्सर का चुनाव वही होता है जो अधिकांश पाठक अपेक्षा करते हैं। YAML एंकर डिफ़ॉल्ट रूप से उत्पन्न नहीं होते क्योंकि हर TOML मान पूरी तरह स्व-निहित है; यदि आप साझा सब-ट्रीज़ चाहते हैं, तो उन्हें हाथ से पेश करें।

कार्यप्रवाह टिप्स

रूपांतरण के बाद, कमिट करने से पहले YAML को किसी लिंटर (yamllint, kubeconform) से गुज़ारें। कन्वर्टर सिंटैक्स का अनुवाद करता है, शैली का नहीं: यह नहीं जान सकता कि क्या आपने फ़ाइल को snake_case या kebab-case का पालन करने की इच्छा रखी, या आप 2-स्पेस या 4-स्पेस इंडेंट चाहते थे। आपकी परियोजना की परंपराएँ यह तय करती हैं।