Powershell: ConvertFrom-Yaml, ConvertTo- यमल

हमने DSC पहलू से समान चर्चा की,
हमें जैसन आधारित कॉन्फ़िगरेशन फ़ाइलों को बदलने की अनुमति देता है, हम चाहते थे कि xml आधारित फ़ाइलों को संशोधित करने के लिए विकल्प हों, YAML आधारित फाइलें, INI आधारित फाइलें RegEx स्वैप का समर्थन करने वाले पाठ मैनीपुलेशन cmdlets के भीतर से।

पीएस में मौजूदा समर्थन की कमी का मतलब है कि हमें ऐसी क्षमता पाने के लिए कड़ी मेहनत करनी होगी।
यह लंबित सामुदायिक योगदान पर रहा है, लेकिन यदि इसे पीएस में बेक किया गया था, तो इससे डीएससी भाग के लिए भी बहुत आसान हो जाएगा।

जब आप मूल रूप से कहते हैं, तो क्या आपका मतलब XML या JSON जैसा है?

वर्तमान सोच यह है कि YAML को PowerShell में बिल्कुल भी बेक नहीं किया जाना चाहिए, इसके बजाय यह एक अलग मॉड्यूल होना चाहिए जिसे आप PowerShell का नया संस्करण चुने बिना अपडेट कर सकते हैं।

यदि YAML को XML की तरह पावरशेल में बेक किया गया, तो यह असंभव होगा (सोचें [xml] " b ")

यदि हम JSON मार्ग पर गए, तो आपके पास YAML के साथ काम करने के लिए cmdlets होंगे - इसलिए वास्तव में PowerShell में बेक नहीं किया जाता है, लेकिन आपके पास YAML अपडेट प्राप्त करने के लिए PowerShell को अपडेट करने की आवश्यकता की कमियां होंगी।

@lzybkr मुझे पता है कि हमने कहा कि हम एक नई लाइब्रेरी में नहीं लाना चाहते हैं, लेकिन मुझे लगता है कि यह एक ऐसी चीज है जिसे हमें भी जहाज करना चाहिए, लेकिन मुझे लगता है कि आधुनिक परिदृश्यों के एक टन को अब YAML की आवश्यकता है।

शायद 6.0 समय सीमा में नहीं, लेकिन हमें इसके बारे में बात करनी चाहिए।

@ ऐरीहिन - मेरे कुछ सरल कार्य हैं जो रजिस्ट्री में हैश एरे को सहेजते हैं और पुनः प्राप्त करते हैं। केवल REG_SZ को हैंडल करें - लेकिन सेटिंग्स के एक साधारण सेट के लिए यह पर्याप्त है - मुझे पता है कि क्या आपको कॉपी चाहिए।

जब मैंने "देशी" कहा तो मुझे गलत लगता है - मैं मुख्य रूप से "अंतर्निहित" का मतलब था - यह मुझे परेशान नहीं करेगा अगर उन्हें शिप किए गए स्क्रिप्ट मॉड्यूल में अपडेट किया जा सकता है।

हमारी पहली चर्चा # 2109

@iSazonov - आह हाँ मैं देख रहा हूँ!

मैंने थ्रेड पर YAML के AWS समर्थन के संदर्भ को देखा - मैं कुछ टेम्पलेट्स को परिवर्तित कर रहा हूं और इसे उपयोगी पाया है: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov सूचक के लिए धन्यवाद, मैं इसे किसी कारण के लिए नहीं मिल सका। हालांकि इसे अच्छी तरह से याद रखें।

उस मूल सूत्र को दोबारा पढ़ते हुए, मुझे लगता है कि हमें भविष्य में किसी समय cmdlets को लागू करना चाहिए और उन्हें गैलरी में शिप करना चाहिए। उनकी गुणवत्ता के आधार पर, और लोगों की कथित उपयोगिता (कुछ रीफैक्टरिंग काम के साथ हम 6.0.0 के बाद करने की उम्मीद करते हैं) के आधार पर, हम इन-बॉक्स बनाम गैलरी-केवल कॉल कर सकते हैं।

हमारे पास https://github.com/PowerShell/platyPS में यमल है

हाँ, यह भयानक होगा, https://github.com/awslabs/aws-cfn-template-flip का उपयोग कर

@MattTunny योगदान करने के लिए आपका स्वागत है! :-)

वहाँ एक Windows सर्वर उपयोगकर्ता के लिए वोट करने के लिए आवाज उठाई :-)

https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11088495-out-of-the-box-support-for-yaml-like-csv-xml-j

यह निश्चित रूप से मूल पीएस 6.1 पुस्तकालय का हिस्सा होना चाहिए। इन दिनों कई चीजें YAML में हैं।

PSGallery पर अब psyaml और powershell-yaml मॉड्यूल हैं, लेकिन दोनों VSTS बिल्ड परिभाषा से एक YAML फ़ाइल को राउंड-ट्रिप करने में भी सक्षम नहीं हैं। अगर मॉड्यूल PowerShell में बेक किया गया है या PSGallery से एक मॉड्यूल है तो मुझे कोई आपत्ति नहीं है।

मुझे आश्चर्य है कि अगर यहां की मुख्य समस्या यह है कि हम जिस तरह से मॉड्यूल तैनात करते हैं वह क्लूनी है। आज, आपको इसका उपयोग करने से पहले एक मॉड्यूल को ढूंढना, विश्वास करना और स्थापित करना होगा। इस (जाहिरा तौर पर) चालाक तरीके से तुलना करें कि जावास्क्रिप्ट var m = require('mymodule') । हो सकता है कि हमारे पास डीएससी के लिए लेकिन देशी पावरस्ले के लिए क्या करना चाहिए। डीएससी में, जब एक मॉड्यूल को एक कॉन्फ़िगरेशन में संदर्भित किया जाता है, तो यह स्वचालित रूप से बिना किसी प्रयास के लक्ष्य नोड पर डाउनलोड और इंस्टॉल हो जाता है। इस तरह से महत्वपूर्ण लेकिन गैर-कोर मॉड्यूल उपलब्ध कराना, "इसे कोर का हिस्सा होना चाहिए" तर्कों को खत्म करना चाहिए। और नेट से डिस्कनेक्ट होने वाले नोड्स के लिए, हमारे पास एक उपकरण हो सकता है जो एक स्क्रिप्ट में निर्भरताओं को एक संग्रह में बंडल करता है जो फिर लक्ष्य पर तैनात किया जाता है। यह है कि एज़्योर डीएससी संसाधन विस्तार कैसे काम करता है - एक उपकरण है जो आवश्यक मॉड्यूल का पता लगाने के लिए एक स्क्रिप्ट को स्कैन करता है फिर एक ज़िप फ़ाइल बनाता है जिसमें आवश्यक सभी चीजें हैं और इसे एक बूँद में प्रकाशित करता है। Azure संसाधन एक्सटेंशन तब इस बूँद को खींचता है, मॉड्यूल स्थापित करता है और स्क्रिप्ट चलाता है।

जब तक यह महत्वपूर्ण है, कुछ के लिए, मैं वास्तव में कभी भी तीसरे पक्ष के पुस्तकालय पर निर्भर नहीं होना चाहता जब तक कि मेरे पास इसका कोई तरीका न हो। तीसरे पक्ष के डेवलपर्स के लिए संभवतः पूरे पारिस्थितिकी तंत्र को तोड़ना आसान है (देखें https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)।

व्यापक रूप से मुद्दों को एक तरफ, वर्तमान में PowerShell के लिए कोई अच्छा YAML मॉड्यूल नहीं है, जैसा कि @bergmeister ने बताया है। यह एक भाषा के लिए बहुत जरूरी है जो स्वचालन के लिए बहुत अधिक केंद्रित है। YAML आधारित कॉन्फ़िगरेशन फ़ाइलें अब बहुत लोकप्रिय हैं और ऐसा करने से बचना बहुत मुश्किल है, भले ही आपको ऐसा करने के लिए किसी टीम की राय के साथ संघर्ष न करना पड़े। XML और JSON को भाषा के मुख्य भागों के रूप में शामिल करने के पीछे तर्क के बारे में सोचें। YAML के लिए मामला वास्तव में इतना अलग नहीं है।

@bgshacklett मैंने

क्या प्लैटिपस पार्सर काफी अच्छा है?

@vors पावरशेल कोर रेपो में प्लैटपीएस यमर्स पार्सर का पुन: उपयोग करने का एक सरल तरीका है?

मैं PowerShell गैलरी में एक अलग आधिकारिक मॉड्यूल के विचार को पसंद करता हूं, जैसे @lzybkr कहता है क्योंकि पुराने पावरशेल संस्करणों में इसका उपयोग करना संभव होगा और इसकी अपनी रिलीज़ हो सकती है। यह sqlserver मॉड्यूल की तरह होगा। @BrucePay अगर यह Microsoft के अपने मॉड्यूल के साथ PowerShell गैलरी में एक पृष्ठ था, तो इसे ढूंढना आसान होगा और हर कोई जानता होगा कि वे उन पर भरोसा कर सकते हैं।

लेकिन मुझे समझ में आएगा कि क्या यह XML और JSON के रूप में पॉवर्स में समर्थित है।

महत्वपूर्ण बात यह है कि यह ConvertFrom-YAML और ConvertFrom-YAML आधिकारिक कार्यों में मौजूद है क्योंकि YAML कॉन्फ़िगरेशन फ़ाइलों के लिए एक व्यापक रूप से उपयोग किया जाने वाला प्रारूप है और इसे @bgshacklett बिंदु के रूप में एक तृतीय-पक्ष मॉड्यूल नहीं होना चाहिए।

मैंने एक ब्लॉग एंट्री टेस्टिंग की और दो मॉड्यूल्स की तुलना करने के लिए जो मैंने पाया है कि मैं YAML फाइलों के साथ काम कर रहा हूं: powershell-yaml ।

उनके अलग व्यवहार हैं क्योंकि आंतरिक रूप से वे विभिन्न वस्तुओं का उपयोग कर रहे हैं:

| मॉड्यूल | मैपिंग | क्रम |
| --------- |: -------------- | ----------- |
| PSYaml | आदेश दिया गया है ऐरे |
| शक्तियां- yaml | Hastable | सूची |

मुझे लगता है कि हमें एक मानक ConvertFrom-YAML और ConvertFrom-YAML ।

दरअसल, ConvertFrom-Yaml -ordered पैरामीटर के साथ कनवर्ट करते समय powershell-yaml OrderedDictionary का उपयोग करता है।
मैं थोड़ी देर के लिए इस मॉड्यूल का सफलतापूर्वक उपयोग कर रहा हूं (DSC कॉन्फ़िगरेशन डेटा के लिए, और रसोई यामल्स के लिए मेरे डेटा मॉड्यूल में), लेकिन एक vsts के साथ परीक्षण करने के लिए परिभाषा का निर्माण नहीं है।

ध्यान रखें कि इसे कॉल करने का सही तरीका है: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (लोग अक्सर -Raw )।

मुझे आश्चर्य है कि हमें MSFT पर और अधिक ओवरहेड डालने और पहिया को फिर से मजबूत करने के लिए एक Microsoft _official_ मॉड्यूल की आवश्यकता क्यों होगी ... हो सकता है कि पहले किसी मौजूदा में योगदान करने की कोशिश कर रहा हो, प्रतिगमन से बचने के लिए परीक्षण जोड़ें, यह सुनिश्चित करने के लिए खुले मुद्दे कि मालिक को पता है समस्याओं का एक बेहतर तरीका है ...
आप जानते हैं कि जब आप 99 मौजूदा कार्यान्वयनों में से एक मानक बनाने की कोशिश कर रहे हैं तो क्या होता है ...

और हां यह भाषा के बाहर बेहतर होगा, मैं मानता हूं कि निर्भरता प्रबंधन बेहतर हो सकता है, पीएस में सब कुछ बंडल करना हालांकि एक समाधान नहीं है।
व्यापक एनपीएम मुद्दा भी प्रक्रिया में विफलता है। कांटा और फिर से प्रकाशित इसे कुछ ही समय में तय किया गया, इंटरनेट के नवीनतम संस्करण में से ऐप्स का निर्माण, यही कारण था कि इसने कई लाइव ऐप को तोड़ दिया।

मैं @gaelcolas से सहमत हूं, मुझे लगता है कि गुणवत्ता बढ़ाने और सुनिश्चित करने के लिए मौजूदा समुदाय मॉड्यूल के मालिकों के साथ काम करने वाले सभी लोगों के साथ यह बेहतर है।

मैं सिर्फ इतना जोड़ूंगा कि इस तरह की परियोजना के लिए परीक्षण में बड़ी संख्या में वास्तविक-विश्व YAML फ़ाइलों के साथ काम करना शामिल होना चाहिए जैसे कि AppVeyor, Travis CI, VSTS, AWS CloudFormation, इत्यादि। YAML डिसेरलाइज़ेशन के साथ अपने स्वयं के अनुभव के लिए, मेरे पास है। सार्वभौमिक रूप से काम कर रहे एक समाधान के साथ थोड़ी सफलता और अंततः पहिया को कई बार सुदृढ़ करना पड़ा। उस अर्थ में, मैं @BrucePay से सहमत

हम इस platyPS मॉड्यूल के बारे में बात कर रहे हैं क्योंकि यह पहले से ही PowerShell सहायता वातावरण में सक्रिय रूप से उपयोग किया जाता है। मुझे लगता है कि MSFT से कोई भी नहीं बता सकता है कि आचार संहिता के कारण यह मॉड्यूल कितना अच्छा है। वे या तो चुपचाप इसे अस्वीकार कर सकते हैं या इसे सुधार सकते हैं।
और यद्यपि हम इस बारे में बहुत पहले से बात कर रहे हैं कि मैं यह नहीं देखता कि हम इस मॉड्यूल के घटकों का उपयोग कैसे कर सकते हैं।
हो सकता है कि @adityapatwardhan और @ SteveL-MSFT अपनी योजनाओं और समयरेखा को विशेष रूप से खोलेंगे क्योंकि नई मदद RFC पहले से ही प्रयोग के चरण में है।

मेरा व्यक्तिगत विचार यह है कि मैं अधिक सामुदायिक मॉड्यूल को सफल होता देखूंगा और Msft से "आधिकारिक" मॉड्यूल की आवश्यकता की तुलना में वास्तविक मानक बन जाऊंगा।

@iSazonov यह एक समाधान के लिए एक चीज है जो एक अच्छी तरह से परिभाषित स्कीमा को क्रमबद्ध / deserializing करने के लिए काम करता है। यह एक और समाधान है जो सामान्य रूप से सभी स्कीमाओं के साथ काम करता है जो कि कंप्लीट यम्लल हैं।

मैं लागत में कटौती के लिए सामुदायिक परियोजनाओं का पुन: उपयोग करने के लिए MSFT की इच्छा को समझता हूं। लेकिन वास्तव में, स्थिति यह है कि MSFT इतने सारे सामुदायिक परियोजनाओं का उपयोग नहीं कर सकता है:

• बहुतों के पास बुरा कोड है, कोई भरोसा नहीं है
• कई परियोजनाएं एक व्यक्ति हैं

MSFT ने 10 साल पहले Powershell विनिर्देशों को प्रकाशित किया है, लेकिन किसी ने भी अभी तक इसे MSFT नहीं किया था।
ओपनएसएसएल प्रोजेक्ट कई वर्षों से मौजूद है लेकिन किसी ने इसे विंडोज पर पोर्ट नहीं किया है जबकि एमएसएफटी ने ऐसा नहीं किया है।
MSFT ने कई हज़ारों API इंटरफेस का खुलासा किया, लेकिन उनमें से कितने यूनिक्स में पोर्ट किए गए थे?
दिलचस्प बात यह है कि कंपनी ने मोनो के पुन: उपयोग के बजाय अपना प्रोजेक्ट .Net कोर क्यों लॉन्च किया?
पॉवरशेल पहले से ही एक वर्ष का है और डेढ़ साल का एक ओपन सोर्स प्रोजेक्ट है, लेकिन मैं देख रहा हूं कि इस रिपॉजिटरी में समुदाय का केवल एक व्यक्ति कोड @markekraus में व्यवस्थित योगदान देता है और केवल एक व्यक्ति ही व्यवस्थित विश्लेषण करता है @ mklement0।
मुझे नहीं लगता कि अगर हम परियोजना को भागों में विभाजित करते हैं, तो हमें अधिक योगदान मिला।
मुझे नहीं लगता कि कल स्थिति बदल जाएगी। मैं इस पर भरोसा नहीं करता।

@markekraus मुझे http://yaml.org/spec/1.2/spec.html#id2802346 :-) पर बहुत उम्मीद है

@iSazonov 3 पार्टी मॉड्यूल के समर्थन, विश्वास और रखरखाव के बारे में महत्वपूर्ण बिंदु बनाता है। कुछ 3rd पार्टी मॉड्यूल जैसे Pester एक सफलता और परिपक्व बन सकते हैं।
हालांकि, किसी को यह नहीं मान लेना चाहिए कि एक महान YAML मॉड्यूल अगले वर्षों में अपने दम पर विकसित होगा। वास्तविकता यह है कि अधिकांश मॉड्यूल उन लेखकों द्वारा प्रकाशित किए जाते हैं जिन्होंने एक विशेष समस्या को हल किया और उनके सामान्य आधार कोड को प्रकाशित करने का अच्छा काम किया। इस तरह हमने 2 मॉड्यूल को समाप्त किया, जिनका उद्देश्य उसी समस्या को हल करना है। आदर्श रूप से किसी को प्रयासों को केंद्रित करने के लिए उन्हें मर्ज करने की आवश्यकता होगी, अन्यथा वे भविष्य में और अधिक बहाव में जा रहे हैं या बस बासी हो जाएंगे और जल्द ही अन्य लोगों द्वारा प्रकाशित अधिक मॉड्यूल होंगे।
एक उचित पार्सर होने की अंतर्निहित समस्या इंगित करती है कि बुनियादी (और प्रयास के मामले में पर्याप्त) जमीनी काम की आवश्यकता है और एक अच्छा हकीम मॉड्यूल की आवश्यकता है।
मैं एक YAML विशेषज्ञ नहीं हूं, लेकिन क्या यह केवल ढीली भाषा विनिर्देश की एक समस्या है या VSTS या AppVeyor जैसी विभिन्न प्रणालियों द्वारा विशिष्ट व्याख्या या यह केवल एक अच्छे पार्सर की कमी है?
मुझे VSCode में YAML लिखने में निराशा हुई और केवल जब इसे VSTS में चलाने के लिए एक त्रुटि मिली कि VSTS पार्सर को यह पसंद नहीं है ...

मेरे लिए यह बातचीत खुले स्रोत की "कोड क्यूरेशन / आर्किटेक्चर" समस्या के साथ एक मामला है।

ओपन सोर्स अच्छा सीडिंग आइडिया और कोड बेस प्रदान करता है - लेकिन अगर सबसे सामान्य समाधान के रूप में अपनाया जाने पर इसे एक गंभीर आर्किटेक्चर आंख नहीं दिया जाता है - तो यह उन वस्तुओं के लिए 10 साल का बग फिक्स है जो एक सभ्य डिजाइन की समीक्षा में ध्यान रखे जा सकते थे। ।

@Bergmeister "परिपक्व सफलताओं" के सच्चे मामलों में यह अक्सर एक सक्रिय

मुझे लगता है कि हम में से कुछ कह रहे हैं "फ़ाइल लिखने के लिए YAML समर्थन समर्थन जैसा है - यह कोर है - इसे उसी तरह से आर्किटेक्चर किया जाना चाहिए => उस कार्यक्षमता के लिए सोने के मानक होने के इरादे से"

1 का संयोजन) 2 के साथ ओपन सोर्स की अर्ध-आर्किटेक्चरल विशेषता) यमल की कोर प्रकृति जो कि हम में से कई को लगता है कि हम अत्यधिक पावरफुल दृष्टिकोण के लिए आग्रह करते हैं जो हम जानते हैं कि Microsoft PowerShell Developers उनके काम पर लागू होते हैं। यह जरूरी नहीं कि सभी अन्य शांत चीजों से खुला स्रोत वास्तव में हमारी मदद कर सकता है।

सॉफ्टवेयर परिपक्वता पर बहुत मान्य बिंदु। मैंने यहां सूचीबद्ध दो मॉड्यूलों को करीब से नहीं देखा है, न ही किसी भी राय बनाने के लिए याम्लडोटनेट पर। कुछ हम देख सकते हैं जैसे हम 6.2.0 के लिए योजना बनाना शुरू करते हैं

मुझे गलत मत समझो, मैं PowerShell टीम और MSFT डेवलपर्स के अनुभव और व्यवस्थित दृष्टिकोण को महत्व देता हूं, मुझे लगता है कि यह उनके लिए गलत है कि वे अपने स्वयं के मुद्रांकित MSFT के एक मॉड्यूल के साथ सभी अंतराल को भरने की कोशिश करें ... यह करता है स्केल नहीं (और हमने पहले ही DSC संसाधनों के साथ समस्या देखी है)।
एमएसएफटी पर निर्भरता बढ़ाने से बशर्ते मॉड्यूल नाजुक हैं, और इससे न तो समुदाय को बढ़ने में मदद मिलती है, न ही पारिस्थितिकी तंत्र की विविधता।
मैं एमएसएफटी के पक्ष में हूं कि वे अपने अनुभव को साझा करने के लिए स्रोत परियोजनाओं को खोलने में योगदान दें और प्रथाओं और गुणवत्ता को बेहतर बनाने में मदद करें, जबकि उन पर निर्भरता पैदा न करें (क्योंकि आप जानते हैं, गिलहरी ...!)।
_MSFT स्वीकृत चीज़ों के अनूठे प्रदाता के रूप में_ एक पुराना मॉडल है जिसे वे पहले से ही शिक्षित करने के लिए संघर्ष करते हैं, और यह समुदाय को इस दृष्टिकोण को प्रोत्साहित करने में मदद नहीं कर रहा है (यानी _I मैं प्रतीक्षा करूँगा, या Microsoft में समस्या का समाधान नहीं करने के लिए moan करूँगा) OSS पारिस्थितिकी तंत्र में रवैया)।

मैं सहमत हूं कि खरोंच से पीएस टीम को फिर से लिखने के बजाय यमर्ल समर्थन कोर है, क्यों न परियोजनाओं के मौजूदा रखरखाव को सुधारने में मदद की जाए, और उन्हें परियोजनाओं को मर्ज करने का मौका दिया जाए और उनसे सुना जाए कि यह क्या ले जाएगा। कोर कार्यक्षमता मॉड्यूल पर पीएस टीम से एक प्रशिक्षुता / सलाह की तरह एक सा।
बस एक नया मॉड्यूल एक समस्या को हल करने के लिए एक इंजीनियर की प्रतिक्रिया की तरह लगता है जो एक इंजीनियरिंग समस्या नहीं है। एक YAML मॉड्यूल को फिर से लिखना PS टीम के लिए एक _easy_ इंजीनियरिंग कार्य है, लेकिन सामुदायिक परिपक्वता समस्या को ठीक करने में मदद नहीं करेगा, और न ही सही प्रोत्साहन देगा।
यमल से निपटने के लिए यामल रणनीतिक आइटम है या नहीं, हालांकि यह MSFT की कॉल है :)

@bergmeister

मैं अपने आप को एक YAML विशेषज्ञ नहीं होने के साथ पेश करता हूँ। मैं इस पर कुछ शोध करने के लिए हुआ था जब मैं कुछ AppVeyor को सेंकना चाहता था जैसे कि yaml अपने फ्रेंकेन-पाइपलाइन में कॉन्फ़िगर करता है। मैंने देखा कि कैसे एक दर्जन या तो सी # परियोजनाएं YAML का उपभोग कर रही थीं। चूंकि PowerShell प्रोजेक्ट्स YamlDotNet का उपयोग करते हैं, इसलिए मैं केवल यह मान सकता हूं कि यह आसान नहीं है। हालाँकि मुझे कम से कम PSYaml और पावरशेल-यम दोनों के साथ खिलवाड़ किया है और कुछ PowerShell प्रोजेक्ट्स पर कम बारीकी से देखा है जो उनका उपयोग करते हैं।

मैं एक YAML विशेषज्ञ नहीं हूं, लेकिन क्या यह केवल ढीली भाषा विनिर्देश की एक समस्या है या VSTS या AppVeyor जैसी विभिन्न प्रणालियों द्वारा विशिष्ट व्याख्या या यह केवल एक अच्छे पार्सर की कमी है?

मुझे संदेह है कि मशीनों द्वारा अधिक आसानी से पठनीय होने के संभावित खर्च पर यह मनुष्यों द्वारा पठनीय होने वाली YAML की प्रकृति है। यह पठनीयता-पहला प्रतिमान उस तरह से विस्तारित होता है जिस तरह से YAML लेखक अपनी YAML फाइलें लिखते हैं। हालांकि परिणामी YAML, YAML कल्पना के तहत आज्ञाकारी है, लेकिन इसे दूर के रूप में इस तरह से पार्स किया जाता है कि वास्तव में उपयोगी वस्तु के रूप में मध्यस्थ के रूप में deserialized ऑब्जेक्ट का उपयोग किए बिना कोड में अनुपयोगी हो।

कहने का तात्पर्य यह है, कि किसी वस्तु के लिए YAML से किसी वस्तु का 90% डिसेरलाइजेशन मुद्दा नहीं है, बल्कि डेटा डिज़ाइन / आर्किटेक्चर है। अन्य 10% समय _is_ पार्सिंग मुद्दों के लिए जिसके लिए मैं केवल "YAML को पार्स करना मुश्किल है, आदमी को चाक कर सकता हूं।" हालाँकि, deserialized ऑब्जेक्ट अक्सर regex-ing की तुलना में थोड़े अधिक उपयोगी होते हैं जो आप खोज रहे हैं ...।

एक उदाहरण के रूप में, AppVeyor.yml में सुरक्षित तार

environment:
  my_var1: value1
  my_var2: value2
  my_secure_var1:
    secure: FW3tJ3fMncxvs58/ifSP7w==

powershell-yaml और YamlDotNet एक वस्तु में परिवर्तित करते हैं, लेकिन तर्क के एक गुच्छा के बिना इसका उपयोग करना सौभाग्य है। एक बार आपके पास यह तर्क है, इस स्कीमा के लिए अच्छा है, लेकिन दूसरे के बारे में क्या?

इन्हीं डेटा डिज़ाइन समस्याओं में से कुछ JSON को प्लेग करते हैं, लेकिन यह (मेरे अनुभव और राय में) मॉडल बनाने में बहुत आसान है जो JSON के अधिक कठोर प्रकृति के कारण उन कमियों के आसपास काम कर सकते हैं। इस धागे में वर्णित किसी भी YAML डीराइलाइज़र्स के लिए मॉडल बनाने की कोशिश करना एक बुरा सपना है अगर यह और जहां यह संभव है।

दी गई, मॉडल JSON cmdlets में वर्तमान में उपलब्ध नहीं है, हालांकि मैं वास्तव में इसे जोड़ना चाहूंगा। अगर मैं "आधिकारिक" YAML मॉड्यूल / cmdlets में कहता हूं तो मैं इसे "आवश्यक" सुविधा के रूप में नीचे रखूंगा। यह विशेष रूप से v5 में पॉवरशेल कक्षाओं को जोड़ने के साथ एक छूटा हुआ अवसर है।

IMO, बस एक वस्तु में YAML स्ट्रिंग्स प्राप्त करना काफी अच्छा नहीं है। यह आसान प्रतीत होता है (कम से कम समय का 90%)। चाल _useful_ ऑब्जेक्ट्स में YAML स्ट्रिंग्स प्राप्त कर रही है। समाधान से कुछ लचीलेपन की आवश्यकता होती है। लेकिन उस लचीलेपन को भी कुछ हद तक स्वीकार्य होना चाहिए और आपको क्रमिक सलाह देने के लिए @lzybkr की आवश्यकता नहीं है ...।

उस प्रभाव के लिए, मैंने कुछ भी नहीं देखा जो सामान्य दायरे में काम करता है। प्रोजेक्ट उपलब्ध समाधानों को अपनाते हैं, और फिर उनके आउटपुट का उपयोग बिचौलियों के रूप में वास्तव में उपयोगी वस्तुओं के लिए करते हैं (पहिया के एक झुंड के लिए अग्रणी जो कि शायद ऊपर की तरफ बेक किया जाना चाहिए)। या, परियोजनाओं YAML से वस्तुओं को पार्स करने में आसानी के लिए YAML पठनीयता समझौता।

@gaelcolas

मैं सहमत हूं कि पीएस टीम को स्क्रैच से फिर से लिखने के बजाय YAML समर्थन कोर है, क्यों न परियोजनाओं के मौजूदा रखरखाव में सुधार करने में मदद की जाए, और उन्हें परियोजनाओं को मर्ज करने का मौका दिया जाए और उनसे सुना जाए कि यह क्या ले जाएगा।

अपने आप से पूछें कि MSFT ने क्यों शुरू किया। कई सालों बाद मोनो को जारी रखने के बजाय .Net कोर प्रोजेक्ट।

MSFT एक समुदाय भी है। और जैसा कि किसी भी समुदाय को अन्य समुदायों के साथ बातचीत की समान समस्याएं हैं।

संदर्भ के लिए, मैं किसी भी काम को खरोंच से नहीं किया जा रहा हूं - कोड को अपनाया जा सकता है - लेकिन फिर सुधार होने से पहले सिस्टम डेवलपमेंट आर्किटेक्चर के नजरिए से जांच की जानी चाहिए। यह समीक्षा और पुन: रिलीज के बाद भी खुला स्रोत

मेरा कहना है कि एक महत्वपूर्ण वास्तुशिल्प समीक्षा और एक टीम से विमुद्रीकरण है जो कोर कोड की बारीकियों को अच्छी तरह से समझता है जो लगभग हर जगह लीवरेज हो जाएगा।

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

@iSazonov देर से उत्तर के लिए क्षमा करें, नहीं platyPS yaml parser अच्छा नहीं है: यह केवल प्रमुख मूल्य जोड़े का समर्थन करता है। हम यमल को उत्पन्न करने के लिए यमलडॉटनेट का भी उपयोग करते हैं।

इसे कोर फीचर सेट से बाहर रखने की ओर भावना के बारे में: पावरबेल में निर्भरता की तुलना में बहुत महत्वपूर्ण अंतर है, कहते हैं, रूबी, पायथन या नोड.जेएस।

इनमें से प्रत्येक भाषा में निर्भरता प्रबंधन उपकरण (बंडलर, पाइप, एनपीएम / यार्न) हैं जो बाहरी निर्भरता के प्रबंधन को आसान बनाते हैं और अधिक महत्वपूर्ण बात, प्रतिलिपि प्रस्तुत करने योग्य हैं। एक Gemfile/Gemfile.lock या package.json/package-lock.json [,yarn.lock] जैसा कुछ होना जो सभी आवश्यक पैकेजों की आसान स्थापना के लिए बनाता है और यह सुनिश्चित करता है कि आप एक बहुत ही विशिष्ट पैच स्तर पर रह रहे हैं एक बहुत ही महत्वपूर्ण अंतर है जो मेरी राय में है, क्या इस मौलिक संभव के लिए तीसरे पक्ष के पुस्तकालयों बनाता है।

शायद ऐसा कुछ है जो इस मुद्दे को हल करने के लिए Nuget के साथ किया जा सकता है, लेकिन मैंने कभी भी PowerShell के लिए निर्भरता प्रबंधन रणनीतियों / पैटर्न का वर्णन करने वाला कोई लेख नहीं देखा है। गैलरी होना बहुत अच्छा है, लेकिन अगर आपको सभी आवश्यक पैकेजों को मैन्युअल रूप से स्थापित करना है, तो यह किसी भी महत्वपूर्ण तैनाती के लिए अक्षम्य हो जाता है।

संपादित करें:
तो ऐसा लगता है कि मैं जो देख रहा हूं वह _may_ पहले से उपलब्ध है: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduled dependency

@bgshacklett एक सुपर अच्छा बिंदु बनाता है।

@ chuanjiao10 - कृपया इस रिपॉजिटरी में कई मुद्दों पर विघटनकारी टिप्पणियों को रोकें, सही समाधान उन्हें Microsoft.PowerShell.Utility मॉड्यूल में शामिल नहीं करेगा और उन्हें PowerShellGallery में होस्ट किए गए एक अलग मॉड्यूल के रूप में शिप करें।

जब आप मूल रूप से कहते हैं, तो क्या आपका मतलब XML या JSON जैसा है?

वर्तमान सोच यह है कि YAML को PowerShell में बिल्कुल भी बेक नहीं किया जाना चाहिए, इसके बजाय यह एक अलग मॉड्यूल होना चाहिए जिसे आप PowerShell का नया संस्करण चुने बिना अपडेट कर सकते हैं।

यदि YAML को XML की तरह पावरशेल में बेक किया गया, तो यह असंभव होगा (सोचें [xml] "b")

यदि हम JSON मार्ग पर गए, तो आपके पास YAML के साथ काम करने के लिए cmdlets होंगे - इसलिए वास्तव में PowerShell में बेक नहीं किया जाता है, लेकिन आपके पास YAML अपडेट प्राप्त करने के लिए PowerShell को अपडेट करने की आवश्यकता की कमियां होंगी।

व्यक्तिगत रूप से यह whilst यह इनबॉक्स में "सही" चीज़ की तरह लगता है मैं सुझाव दूंगा कि वास्तव में ऐसा करने के लिए सही चीज़ नहीं है

@lzybkr मुझे पता है कि हमने कहा कि हम एक नई लाइब्रेरी में नहीं लाना चाहते हैं, लेकिन मुझे लगता है कि यह एक ऐसी चीज है जिसे हमें

शायद 6.0 समय सीमा में नहीं, लेकिन हमें इसके बारे में बात करनी चाहिए।

एक बाहरी मॉड्यूल शिपिंग ज्यादा मेरे विचार में बेहतर रूप में इस्तेमाल किया निचले स्तर हो सकता है और IMO यह जहां संभव हो उच्च गुणवत्ता को पाने के लिए कम PowerShell की टीम ऐसा करने के लिए और काम अधिक समुदाय PowerShell टीम की मदद से इस ड्राइव करने के लिए है।

फिर @ chuanjiao10 से पहले यह तय किया गया था कि # 2109 में YAML Cmdlets को PowerShell Core में न डाला जाए और इसे ठीक से ठुकरा दिया जाए, क्योंकि इसे भी अब ठुकरा दिया जाना चाहिए।

के बारे में

एकता में बल है। एक अमेरिकी जिसे एक कार की आवश्यकता है, क्या आपने उसे वॉल-मार्ट को पहिया खरीदने, अमेज़ॅन पर जाने के लिए एक इंजन खरीदने के लिए, और hisself (diy a car) को संयोजित करने के लिए देखा है?

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

इस बिंदु के बारे में

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

मैंने इसके लिए # 1979 के अनुसार जितना संभव हो उतने मॉड्यूल में निर्मित करने की वकालत की है और यह देखना चाहूंगा कि PowerShell Core जितना संभव हो उतना दुबला हो जो कि # 5681 में आगे चर्चा के लिए शुरू किया गया है।

और फिर से

YAML के खिलाफ भेदभाव मत करो, JSON की चापलूसी मत करो।

मैं यमल के साथ भेदभाव नहीं कर रहा हूं और न ही जसन की चापलूसी कर रहा हूं क्योंकि दोनों में उनकी खामियां हैं, लेकिन दोनों के पास उनके उपयोग हैं और अगर मैं पावरशेल में जोंस cmdlets को शिपिंग नहीं करने के लिए प्रभावित करने में सक्षम था, तो मैं ठीक वैसा ही कर सकता था जैसा मैं यहां कर रहा हूं।

मुझे लगता है कि इस चर्चा को थोड़ा सा पलटना फायदेमंद हो सकता है। विशेष रूप से, क्या मुख्य भाषा में शामिल किए जाने वाले YAML के पक्ष में विशिष्ट उपयोग के मामलों को सूचीबद्ध करने की इच्छा होगी और क्यों PowerShell गैलरी में एक मॉड्यूल ने कहा कि उपयोग के मामले को संबोधित करने में अपर्याप्त है? उस बिंदु पर हमारे पास एक आवश्यकता-संचालित चर्चा हो सकती है और संभावित रूप से हाथ में समस्या के लिए एक व्यावहारिक समाधान मिल सकता है।

मेरा प्राथमिक उपयोग मामला ऑपरेटिंग सिस्टम और एप्लिकेशन परिनियोजन दोनों के नंगे धातु स्वचालन के लिए है। कम से कम एक मामले में मैं एक YAML फ़ाइल पढ़ना चाहता हूं, जिसने मापदंडों को समझने के लिए मेरी स्क्रिप्ट को कॉल किया।
अक्सर इन मामलों में हमारे लिए बाहरी, गैर-SLAed पर निर्भरता, सेवा एक बहुत बड़ी संख्या नहीं है। यह उत्पादन स्केलिंग गतिविधियों को प्रभावित कर सकता है।

कि शब्दाडंबर कोर के सबसे मौलिक पदचिह्न में शिपिंग के लिए मेरा उपयोग मामला है।

मैं जीवंत चर्चा की सराहना करता हूं, आइए इसे नागरिक बनाए रखने की कोशिश करें :)

@ पावरशेल / पावरशेल-समिति ने इस पर पहले चर्चा की थी। हम सहमत हैं कि YAML का समर्थन करना महत्वपूर्ण है कि यह आज कैसे प्रचलित है। हम ऐसे और भी मॉड्यूल देखना चाहते हैं जिन्हें हम वर्तमान में PSCore6 में शिप करते हैं ताकि आप PSCore6 की एक न्यूनतम स्थापना के साथ शुरू करें और फिर आपको जो कुछ भी आवश्यक हो उसे जोड़ दें (मेटामॉड्यूल्स के साथ आपको 10+ मॉड्यूल जोड़ने की आवश्यकता नहीं है, सिर्फ DevOps , उदाहरण के लिए)। इसलिए YAML के बारे में, वर्तमान सोच यह है कि यह एक अलग मॉड्यूल होना चाहिए (मैं PowerShell org के तहत एक रेपो बना सकता हूं यदि कोई भी इस प्रोटोटाइप को शुरू करने के लिए तैयार है, तो मेरी टीम में अभी बैंडविड्थ नहीं है)। यमलडॉटनेट (या अन्य 3 पार्टी लाइब्रेरी) का उपयोग करना एक बार एक तकनीक, लाइसेंसिंग, समर्थन बिंदु से मूल्यांकन करने के लिए ठीक है (इसी तरह से हम Json.Net पर निर्भरता कैसे लेते हैं)। हालांकि, पिछली बार जब हमने YAML और YamlDotNet को देखा, तो समस्या यह है कि YAML के कार्यान्वयन में व्यापक रूप से भिन्नता है और लाइब्रेरी ने उस सब कुछ का समर्थन नहीं किया जो वहाँ (यहां तक ​​कि कुछ लोकप्रिय भी हैं)।

मैं सिर्फ इतना कहूंगा कि YAML का समर्थन कुछ ऐसा है जो मैं टीम को 6.2 रिलीज में देखना चाहता हूं।

@ स्टीवएल-एमएसएफटी आप इस मुद्दे और https://github.com/dotnet/corefx/issues/454578 पर आधारित टिप्पणी कर सकते हैं

in.my राय है कि कन्वर्टफ्रॉम-जोंस, कन्वर्टफ्रॉम-जैमल को एक ही स्थिति है, या तो बाहर स्थानांतरित या अंदर बनाया गया है।

मैं इस बात की वकालत कर रहा हूं कि हमें JSON cmdlets को परियोजना से बाहर ले जाना चाहिए। काफी कुछ बदलाव हैं जो बहुत से बदलाव करना चाहते हैं, जो कि काफी हद तक टूटने वाले बदलाव होंगे, लेकिन वे नहीं किए जा सकते क्योंकि cmdlets PowerShell से बंधे हैं। उन्हें प्रोजेक्ट से बाहर ले जाने से हमें cmdlets मॉड्यूल के एक नए प्रमुख संस्करण में बड़े बदलाव करने की अनुमति मिलती है, और एक पुराने संस्करण के साथ PowerShell जहाज है जो बैकवर्ड संगतता प्रदान करता है, लेकिन उपयोगकर्ताओं को यदि वे चाहें तो अपडेट करने की अनुमति देते हैं .... हालांकि, यह है इस तरह के बाहरी मॉड्यूल को शामिल करने के लिए एक बड़ी परेशानी, IMO।

इसके बजाय हम JSON और Pester के साथ अपनी गलतियों से सीखते हैं, मनमाने ढंग से YAML के साथ उसी तरह व्यवहार करते हैं। यह निश्चित रूप से पावरशेल की मुख्य कार्यक्षमता का हिस्सा नहीं होना चाहिए, लेकिन निश्चित रूप से समुदाय और पीएस टीम के बीच साझा स्वामित्व के साथ आधिकारिक तौर पर समर्थित मॉड्यूल का कुछ प्रकार होना चाहिए।

मुझे वह विचार पसंद है। JSON Cmdlets को स्थानांतरित करने से सतह वर्कफ़्लो समस्याओं में मदद मिलेगी जो वर्तमान में बाहरी मॉड्यूल पर कठिन निर्भरता के साथ मौजूद हैं।

लेकिन yaml सिस्टम एडमिनिस्ट्रेटर, स्क्रिप्ट डेवलपर्स के लिए महत्वपूर्ण है, इन उपयोगकर्ताओं को yaml कमांड की आवश्यकता होती है।

उन्हें उनकी आवश्यकता हो सकती है लेकिन इसका मतलब यह नहीं है कि उन्हें सीधे PowerShell के भीतर शामिल करने की आवश्यकता है क्योंकि एक बाहरी मॉड्यूल स्वीकार्य से अधिक है और कोर रिपॉजिटरी में बंधे किसी भी चीज़ की तुलना में अधिक लचीला समर्थन जीवनचक्र है।

मुझे यह कहना है कि @ स्टीव-एमएसएफटी का विचार DevOps मेटा मॉड्यूल का वास्तव में लंबी अवधि में इसके लिए सही तरीका है क्योंकि यह विभिन्न उपयोगकर्ता सेटों के लिए संकुल का एक सरल सेट प्राप्त करने की अनुमति देता है जो बहुत आसान प्रबंधित होते हैं एक बाहरी निर्भरता के रूप में यह एक आंतरिक होने के नाते, जो मुझे बहुत समझ में आता है, हालांकि उन्हें तकनीकी स्टैक्स के आधार पर मेटा मॉड्यूल होना चाहिए क्योंकि अगर मैं खिड़कियों पर हूं और अभिषेक का उपयोग नहीं कर रहा हूं तो मुझे yaml cmletlets की आवश्यकता क्यों होगी खिड़कियाँ?

जबकि @ chuanjiao10 द्वारा उल्लिखित yml का उपयोग करके लिनक्स दुनिया में बड़ी संख्या में उपयोगकर्ता हैं, यह विंडोज़ की दुनिया में ऐसा नहीं है, जो कि समग्र पॉवरशेल उपयोग की मेरी समझ से अभी भी काफी हद तक पॉवरशेल 5.1 से चिपक जाता है क्योंकि यह उनके सिस्टम पर इनबॉक्स है। और यमल cmdlets को बंडल करते हुए लिनक्स उपयोगकर्ताओं को विंडोज उपयोगकर्ताओं के लिए एक अनावश्यक अतिरिक्त बंडल आइटम की तरह यह मेरे लिए मदद कर सकता है, लेकिन उपयोगकर्ताओं के दोनों सेटों का इलाज करने के लिए यह एक ही अर्थ देता है कि यह एक बाहरी मॉड्यूल है जो उपयोगकर्ताओं के दोनों सेटों को समाप्त करता है आवश्यकतानुसार उपयोग कर सकते हैं

क्या कोई है जो एक मालिक बनना चाहता है और इन cmdlets के साथ एक अलग परियोजना में है?

@iSazonov ऐसा लगता है कि Corefx वर्तमान में बिल्ट-इन YAML सपोर्ट में दिलचस्पी नहीं ले रहा है। यमलडॉटनेट सबसे लोकप्रिय पुस्तकालय प्रतीत होता है, क्या एमआईटी लाइसेंस प्राप्त है, सक्रिय रूप से बनाए रखा जाता है, इसलिए मैं वहां शुरू करूंगा। एक समुदाय संचालित परियोजना अद्भुत होगी और संभवत: जितनी जल्दी हो सके, अगर आप इसे पावरशेल टीम पर छोड़ दें।

@ स्टीवएल-एमएसएफटी को अच्छे कारण के लिए लगता है - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255 जो मुझे उम्मीद है कि इस विशेष पुस्तकालय पर भरोसा कम हुआ है।

ऐसा लगता है कि Corefx वर्तमान में बिल्ट-इन YAML सपोर्ट में दिलचस्पी नहीं ले रहा है।

CoreFX टीम उपयोग के मामलों के बारे में पूछती है। यदि PowerShell प्रोजेक्ट कहेगा कि हमें API की आवश्यकता है तो वे API को जोड़ने पर विचार करेंगे।

एक समुदाय संचालित परियोजना अद्भुत होगी और संभवत: जितनी जल्दी हो सके, अगर आप इसे पावरशेल टीम पर छोड़ दें।

ओह, मुझे केवल एक ही परियोजना का पता है - पेस्टर। और मैं याम्ल समुदाय संचालित परियोजना में विश्वास नहीं करता - यह पिछले कुछ वर्षों में क्यों नहीं दिखाई दिया है?
मैं इस परियोजना को शुरू करने पर विचार करता हूं, लेकिन इसने मुझे रोक दिया कि मैं उस स्तर की गुणवत्ता, अनुपालन और सुरक्षा में कभी नहीं पहुंच सकता जो एमएसएफटी को चाहिए।
मुझे लगता है कि MSFT सुरक्षा ऑडिट के बिना परियोजनाओं पर कभी भी भरोसा और उपयोग करने में सक्षम नहीं होगा।
इसका काम करने के लिए मेरे पास केवल एक विचार है। MSFT GitHub Core Core और PowerShell जैसी परियोजनाएं "MSFT के स्वामित्व में" और "MSFT द्वारा संचालित" हैं। नया प्रोजेक्ट प्रकार "MSFT द्वारा स्वामित्व", "समुदाय द्वारा संचालित" और "MSFT द्वारा उल्लेखित" हो सकता है। "सलाह" के तहत मेरा मतलब है पर्यावरण का कार्यान्वयन जहां परियोजना पर भरोसा किया जाएगा और उच्च गुणवत्ता।

Microsoft को PowerShell Core के लिए YAML सपोर्ट इन-बॉक्स बंडल करने की आवश्यकता है। सादा और सरल।

@brettjacobson हां, यह सादा, सरल और उच्च गुणवत्ता वाला होगा लेकिन MSFT टीम के पास इतने संसाधन नहीं हैं। क्या आप योगदान करने के लिए तैयार हैं? :-)

@brettjacobson - Microsoft को

यह किसी ऐसी चीज़ के लिए एक अनुरोध है जो कई want और अंततः use लेकिन एक महत्वपूर्ण need और इसलिए प्राथमिकता पाने के लिए _unlikely_ है जो वास्तव में एक "स्टीव-एमएसएफटी" है जब वह निम्नलिखित कहे तो पाने की कोशिश कर रहा था

मैं सिर्फ इतना कहूंगा कि YAML का समर्थन कुछ ऐसा है जो मैं टीम को 6.2 रिलीज में देखना चाहता हूं।

एक समुदाय संचालित परियोजना अद्भुत होगी और संभवत: जितनी जल्दी हो सके, अगर आप इसे पावरशेल टीम पर छोड़ दें।

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

CoreFX टीम उपयोग के मामलों के बारे में पूछती है। यदि PowerShell प्रोजेक्ट कहेगा कि हमें API की आवश्यकता है तो वे API को जोड़ने पर विचार करेंगे।

@iSazonov IMHO

तो क्या आप एक "महान" तीसरे पक्ष के पुस्तकालय की प्रतीक्षा करने जा रहे हैं या जेम्स न्यूटन-किंग से Newtonsoft.Yaml बनाने के लिए कहेंगे? :-)

@NextTurn हम .Net Core 3.0 में नया Json (बहुत तेजी से (Newton.Json की तुलना में अधिक तेज़) और बहुत लचीला) कार्यान्वयन प्राप्त करेंगे।
यदि समुदाय से महान अनुरोध है तो CoreFX टीम हमेशा नया एपीआई जोड़ सकती है। अगर वहाँ कई परियोजना है जो YAML वे जोड़ सकते हैं से लाभ हो सकता है। वर्तमान में ऐसा कोई अनुरोध नहीं है।

मैं क्या प्रत्येक नया pwsh प्रणाली नहीं करता हूं? मैं Install-Module -Name powershell-yaml करता हूं।

मोंगो, कुबेरनेट्स, इस्तियो, अन्सिबल, इसे नाम दें - मैं उपयोग करता हूं। ये सभी YAML हैं और मेरे पास YAML टेम्प्लेट और ट्रांसफॉर्मेशन हैं। pwsh DevOps के लिए अच्छा लगता है और वे YAML बोलते हैं।

@ dzmitry-lahoda जारी # 5681 में PowerShell का एक 'समृद्ध' संस्करण होने का प्रस्ताव है, जो सामान्य मॉड्यूल जैसे कि Pester , आदि के साथ जहाज प्रदान करते हैं। कृपया इस अंक में पोस्ट करें लेकिन यह देखते हुए कि ऐसा नहीं लगता है वर्तमान में उपलब्ध 2 यम्ल मॉड्यूलों के बीच स्पष्ट विजेता और वे एक-दूसरे को पसंद कर रहे हैं, यह पसंदीदा चुनने के लिए एक कठिन निर्णय हो सकता है।

मैं केवल एक YAML देखता हूं :(

Pester , ये। अपने pwsh कंटेनर अनुप्रयोगों के लिए YAML रीडर के विपरीत, मेनलाइन में BDD फ्रेमवर्क को भारी करना।

क्या यह धागा निष्कर्ष निकाला गया है। Microsoft द्वारा उपयोग करने के लिए अनुशंसित (या सुझाया गया) मॉड्यूल क्या है?
DevOps पाइपलाइन yaml का उपयोग करती है। मेरे सभी परिनियोजन स्वचालन को पॉवरशेल के साथ बनाया गया है। लगता है यम और शक्तियां अच्छा नहीं खेलती हैं। क्या Azure DevOps स्वचालन के लिए पॉवरशेल एक बुरा विकल्प है?
मेरे भविष्य के उपयोग / नवाचार पर ध्यान से सोचने की आवश्यकता है और कुछ दिशा की सराहना करेंगे।
अग्रिम में धन्यवाद!

@dirkslab आप https://github.com/cloudbase/powershell-yaml का उपयोग कर सकते हैं

GitHub

cloudbase / powershell-YAML

YAML प्रारूप हेरफेर के लिए PowerShell CmdLets। GitHub पर एक खाता बनाकर क्लाउडबेस / पावरशेल-यम डेवलपमेंट में योगदान करें।

धन्यवाद @iSazonov , वह समाधान है जिसका मैं इस समय परीक्षण कर रहा हूं। अब तक का समाधान ठीक काम करता है। समाधान का उपयोग करने में शायद कुछ भी गलत नहीं है।

ध्यान दें कि पॉवरशेल-यमल का उपयोग करके आपको एक अविश्वसनीय मॉड्यूल को ठीक करने की आवश्यकता है। यह वह हिस्सा है जिसे मैं समझने के लिए जूझ रहा हूं। Microsoft yaml पाइपलाइनों का उपयोग करने की सलाह देता है। Microsoft (या कम से कम यह थ्रेड) 3 पार्टी मॉड्यूल का उपयोग करने का सुझाव देता है ताकि आप yaml config को पॉवरशेल के साथ एकीकृत कर सकें, लेकिन किसी भी चीज़ का समर्थन या अनुशंसा न करें। आप कैसे समझाते हैं कि तार्किक रूप से उद्यम के लिए।
मेरा अब तक का अनुभव हमेशा से यही रहा है कि यदि आप Microsoft समर्थित समाधानों का उपयोग नहीं करते हैं, तो यह आपके समाधान के मुद्दों के लिए Microsoft से किसी भी तरह की सहायता या समझ को म्यूट कर देगा (यदि कोई समस्या पैदा करने वाला कोई भी हिस्सा स्पर्श नहीं करता है तो कोई बात नहीं) मात्र तथ्य यह है कि आप असमर्थित हिस्सा है आमतौर पर कोई समर्थन / जिम्मेदारी में परिणाम है।
हो सकता है कि इस ओपनसोर्स युग में चीजें बदल गई हों। Microsoft की सरल आधिकारिक प्रतिक्रिया और मार्गदर्शन मुझे सहजता से स्थापित करेगा और मुझे समझने में मदद करेगा।

आपकी प्रतिक्रिया की सराहना की। सादर।

@dirkslab मुझे लगता है कि आपका

CoreFX टीम उपयोग के मामलों के बारे में पूछती है

स्पष्ट लाभ से देखें कि yaml आज हमारे चारों ओर CI / CD में है और कॉन्फ़िगरेशन सिस्टम की संख्या, ConvertTo-Yaml का अतिरिक्त लाभ मानव पठनीय प्रारूप में nast हैशटेबल का ConvertTo-Json विपरीत, जिसका हमें अभी उपयोग करना है। जो आउटपुट को बहुत पठनीय नहीं बनाता है।

मैं इस बीच में राइट-हैशटेबल का उपयोग करता हूं, लेकिन यह ओटीबी के लिए बहुत अच्छा होगा।

मैं यमल से नफरत करता हूं, मैं वास्तव में इससे नफरत करता हूं। हालाँकि, एमएस टीम के लायक कुछ पहलुओं पर विचार किया जा रहा है:

1. यह CI की डिफ़ैक्टो भाषा बन गई है: docker-compose.yaml, ansible, kuber, k8s, github, Circle, azure, ... और यह CI से क्रॉल करने वाली परियोजनाओं में लगता है जो इसका उपयोग करते हैं।

$config = Invoke-WebRequest https://$ciserver/api/projects/$project/config.yaml | ConvertFrom-Yaml
$config['started'] = Get-Date
$config['options'] = $options
Invoke-WebRequest -Method Post https://$ciserver/api/projects/$project/build -Body ($config | ConvertTo-Yaml)

महाशक्ति के साथ इस जहाज के होने से सीआई समूहों को इंजील करने में परिवर्तनकारी होगा।
"अगर हम एमएस पावरशेल पर स्विच करते हैं तो हम स्वचालित रूप से" -> "मुझे और बता सकते हैं?"
बनाम
"अगर हम ms के शक्तियॉ पर जाते हैं और गैलरी से कुछ स्क्रिप्ट डाउनलोड करते हैं" -> "नहीं"

1. वास्तव में, यह बाय-बाय है, लेकिन yaml json का एक सुपरसेट है, जैसे कि json yaml का संक्षिप्त रूप है, एक कुशल yaml parser एक कुशल json पार्सर है,

क्या यह 7.1 के लिए पुनर्विचार किया जा सकता है? मैं भी एक अविश्वसनीय मॉड्यूल और कुछ का उपयोग करने के साथ समस्या है इसलिए DevsOpsy वास्तव में PowerShell के मूल निवासी होना चाहिए।

IMHO, YAML JSON और CSV के रूप में लोकप्रिय है, और PowerShell में YAML के लिए इनबॉक्स कन्वर्टर्स नहीं होना दुख की बात है। इनबॉक्स होने के बाद YAML कन्वर्टर्स यह भी सुनिश्चित करेंगे कि उनका व्यवहार JSON कन्वर्टर्स के बराबर हो, जो सामुदायिक मॉड्यूल के मामले में नहीं है।

मुझे गलत मत समझो - मैं सराहना करता हूं कि लोग समुदाय के लिए मॉड्यूल बनाते हैं, लेकिन दुनिया की वर्तमान स्थिति में, YAML रूपांतरण तालिका दांव है - हम लोगों को JSON रूपांतरण के लिए 3-पार्टी मॉड्यूल डाउनलोड करने की उम्मीद नहीं करते हैं।