Powershell: تحويل من يمل ، تحويل إلى يامل

أجرينا مناقشة مماثلة من جانب DSC ،
للسماح لنا بتغيير ملفات التكوين المستندة إلى json ، أردنا الحصول على خيارات لتعديل الملفات المستندة إلى xml والملفات المستندة إلى YAML والملفات المستندة إلى INI التي تدعم مقايضات RegEx من داخل أوامر cmdlets الخاصة بمعالجة النص.

يعني نقص الدعم الحالي في PS أنه يتعين علينا العمل بجد للحصول على هذه القدرة.
لقد كانت معلقة مساهمة المجتمع المعلقة ، ولكن إذا تم تحويلها إلى PS ، فسوف تجعل الأمر أسهل بكثير بالنسبة لجزء DSC أيضًا.

عندما تقول بشكل أصلي ، هل تقصد مثل XML أو JSON؟

التفكير الحالي هو أنه لا ينبغي دمج YAML في PowerShell على الإطلاق ، بل يجب أن تكون وحدة منفصلة يمكنك تحديثها دون التقاط إصدار جديد من PowerShell.

إذا تم دمج YAML في PowerShell مثل XML ، فسيكون ذلك مستحيلًا (فكر في [xml] " b ")

إذا ذهبنا إلى مسار JSON ، فسيكون لديك أوامر cmdlets للعمل مع YAML - لذلك لم يتم خبزها حقًا في PowerShell ، ولكن لا يزال لديك عيوب الحاجة إلى تحديث PowerShell للحصول على تحديثات YAML.

lzybkr أعلم أننا قلنا إننا لا نريد إحضار مكتبة جديدة ، لكنني أعتقد أن هذا شيء قد نحتاج إلى إعادة تقييمه. من الناحية المثالية ، يجب علينا أيضًا شحن الوحدة النمطية في المعرض ، لكنني أعتقد أن عددًا كبيرًا من السيناريوهات الحديثة يتطلب YAML الآن.

ربما ليس في الإطار الزمني 6.0 ، لكن يجب أن نتحدث عنه.

ArieHein - لدي بعض الوظائف البسيطة التي تحفظ وتسترجع مصفوفة التجزئة إلى التسجيل. تعامل فقط مع REG_SZ - ولكن يكفي لمجموعة بسيطة من الإعدادات - أخبرني إذا كنت تريد نسخة.

لقد أخطأت في التفسير عندما قلت "أصلية" - كنت أعني في الأساس "مدمجة" - فلن يزعجني إذا تم شحنها وحدات البرنامج النصي التي يمكن تحديثها.

مناقشتنا الأولى # 2109

iSazonov - آه نعم أرى!

لقد لاحظت الإشارة إلى دعم AWS لـ YAML في الخيط - لقد قمت بتحويل بعض القوالب ووجدت هذا مفيدًا: https://github.com/awslabs/aws-cfn-template-flip

iSazonov بفضل المؤشر ، لم أتمكن من العثور عليه لسبب ما. تذكر جيدا ، مع ذلك.

عند إعادة قراءة هذا الموضوع الأصلي ، أعتقد أنه يجب علينا بالتأكيد تنفيذ أوامر cmdlets في وقت ما في المستقبل ، وشحنها في المعرض. استنادًا إلى جودتها وفائدة الأشخاص المتصورة (جنبًا إلى جنب مع بعض أعمال إعادة البناء التي نأمل القيام بها بعد 6.0.0) ، يمكننا إجراء المكالمة الواردة في الصندوق مقابل الاتصال بالمعرض فقط.

لدينا Yaml في https://github.com/PowerShell/platyPS

نعم سيكون هذا رائعًا ، انتهى به الأمر باستخدام https://github.com/awslabs/aws-cfn-template-flip للتحويل

MattTunny مرحبا بكم في المساهمة! :-)

هناك صوت مستخدم Windows Server مفتوح للتصويت له :-)

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

يجب أن يكون هذا بالتأكيد جزءًا من مكتبة PS 6.1 الأصلية. الكثير من الأشياء هذه الأيام في YAML.

توجد الآن وحدات psyaml و powershell-yaml على PSGallery ولكن كلاهما غير قادرين حتى على نقل ملف YAML من تعريف بناء VSTS. لا أمانع إذا كانت الوحدة مخبوزة في PowerShell أم أنها وحدة من PSGallery.

أتساءل عما إذا كانت المشكلة الأساسية هنا هي الطريقة الصعبة التي ننشر بها الوحدات. اليوم ، عليك أن تجد وحدة تثق بها وتثبتها قبل أن تتمكن من استخدامها. قارن هذا بالطريقة اللامعة (على ما يبدو) التي تعمل بها Javascript var m = require('mymodule') . ربما يجب أن يكون لدينا طريقة ما للقيام بما يفعله DSC ولكن من أجل PowerShell الأصلي. في DSC ، عندما تتم الإشارة إلى وحدة نمطية في التكوين ، يتم تنزيلها وتثبيتها تلقائيًا على العقدة الهدف دون أي جهد يدوي. يجب أن يؤدي توفير وحدات حرجة ولكن غير أساسية بهذه الطريقة إلى التخلص من الحجج "يجب أن تكون جزءًا من جوهر". وبالنسبة للعقد التي تم فصلها عن الشبكة ، يمكن أن يكون لدينا أداة تجمع التبعيات في البرنامج النصي في أرشيف يتم نشره بعد ذلك على الهدف. هذه هي الطريقة التي يعمل بها ملحق موارد Azure DSC - هناك أداة تقوم بمسح نص برمجي لمعرفة الوحدات المطلوبة ثم تقوم بإنشاء ملف مضغوط يحتوي على كل ما هو مطلوب وتنشره على blob. يقوم ملحق مورد Azure بعد ذلك بسحب هذه النقطة الثنائية الكبيرة ، ويقوم بتثبيت الوحدات النمطية وتشغيل البرنامج النصي.

بالنسبة لشيء بهذه الأهمية ، فأنا لا أرغب أبدًا في الاعتماد على مكتبة تابعة لجهة خارجية ما لم يكن لدي طريقة لبيعها. من السهل جدًا على مطوري الطرف الثالث كسر الأنظمة البيئية بأكملها (راجع https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

بغض النظر عن المشكلات الأوسع نطاقًا ، لا توجد حاليًا وحدة YAML جيدة لـ PowerShell ، كما أشار bergmeister . هذا أمر لا بد منه للغة تركز بشدة على الأتمتة. تحظى ملفات التكوين المستندة إلى YAML بشعبية كبيرة الآن ومن الصعب جدًا تجنبها حتى لو لم تكن مضطرًا للتعامل مع آراء فريق للقيام بذلك. فكر في الأسباب الكامنة وراء تضمين XML و JSON كأجزاء أساسية من اللغة. حالة YAML ليست مختلفة حقًا.

bgshacklett مما سمعته من شباب الدمى ، لا يوجد محللون جيدون لـ YAML :-)

هل محلل platyPS جيد بما فيه الكفاية؟

vors هل هناك طريقة بسيطة لإعادة استخدام محلل platyPS YAML في PowerShell Core repo؟

أفضل فكرة وجود وحدة رسمية منفصلة في PowerShell Gallery مثل lzybkr يقول لأنه سيكون من الممكن استخدامها في إصدارات powerhell الأقدم ويمكن أن يكون لها إصداراتها الخاصة. سيكون ذلك مثل وحدة sqlserver . BrucePay إذا كانت صفحة في PowerShell Gallery مع وحدات Microsoft الخاصة بها ، فسيكون من الأسهل العثور عليها

لكنني سأفهم ما إذا كان مدعومًا في Powershell كـ XML و JSON.

الشيء المهم هو أنه يوجد وظائف رسمية ConvertFrom-YAML و ConvertFrom-YAML لأن YAML هو تنسيق مستخدم على نطاق واسع لملفات التكوين ولا ينبغي أن يكون وحدة طرف ثالث ، كما يشير bgshacklett .

لقد قمت باختبار إدخال مدونة ومقارنة الوحدتين اللتين وجدتهما للعمل مع ملفات YAML: owershell -yaml .

لديهم سلوكيات مختلفة لأنهم يستخدمون كائنات مختلفة داخليًا:

| وحدة | التعيينات | متواليات |
| --------- |: -------------- | ----------- |
| بسيامل | القاموس المرتب | صفيف |
| بوويرشيل يامل | مستعجل | قائمة |

أعتقد أننا بحاجة إلى معيار ConvertFrom-YAML و ConvertFrom-YAML .

في الواقع ، يستخدم ConvertFrom-Yaml في powershell-yaml OrderedDictionary عند التحويل باستخدام المعلمة -ordered .
لقد كنت أستخدم هذه الوحدة بنجاح لفترة من الوقت (في وحدة Datum الخاصة بي لبيانات تكوين DSC ، ومع yamls للمطبخ) ، ولكن ليس لديك تعريف بناء vsts لاختباره.

ضع في اعتبارك أن الطريقة الصحيحة للاتصال بها هي: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (غالبًا ما يفقد الأشخاص -Raw ).

أتساءل لماذا نحتاج إلى وحدة Microsoft _official_ ، ووضع المزيد من النفقات العامة على MSFT وإعادة اختراع العجلة ... ربما نحاول المساهمة في واحدة موجودة أولاً ، وإضافة اختبارات لتجنب الانحدار ، وفتح المشكلات للتأكد من أن المالك يعرف المشاكل هو نهج أفضل ...
أنت تعرف ما يحدث عندما تحاول إنشاء معيار من بين 99 تطبيقًا موجودًا ...

ونعم ، سيكون من الأفضل خارج اللغة ، أوافق على أن إدارة التبعية يمكن أن تكون أفضل ، ولكن تجميع كل شيء في PS ليس حلاً.
تعد مشكلة npm الواسعة أيضًا فشلًا في العملية. تم إصلاحها في وقت قصير جدًا ، حيث تم إصلاحها من خلال Fork وإعادة النشر ، وكان إنشاء تطبيقات من أحدث إصدار من الإنترنت هو السبب في كسر العديد من التطبيقات الحية.

أتفق مع gaelcolas وأعتقد أن هذا أفضل مع عمل الجميع مع مالكي وحدة المجتمع الحالية لرفع الجودة

سأضيف فقط أن الاختبارات لمثل هذا المشروع يجب أن تتضمن العمل مع عدد كبير من ملفات YAML الواقعية لأشياء مثل AppVeyor و Travis CI و VSTS و AWS CloudFormation وما إلى ذلك. لتجربتي الخاصة مع YAML deserilization ، لقد حصلت على القليل من النجاح مع حل واحد يعمل عالميًا واضطر في النهاية إلى إعادة اختراع العجلة عدة مرات. بهذا المعنى ، أتفق مع BrucePay "لا يوجد محللون جيدون لـ YAML".

نحن نتحدث عن وحدة platyPS هذه لأنها مستخدمة بالفعل في بيئة تعليمات PowerShell. أعتقد أنه لا يمكن لأحد من MSFT معرفة مدى جودة هذه الوحدة بسبب مدونة قواعد السلوك. يمكنهم إما رفضه بصمت أو تحسينه.
وعلى الرغم من أننا كنا نتحدث عن هذا منذ وقت طويل ، إلا أنني لا أرى كيف يمكننا استخدام مكونات هذه الوحدة هنا بطريقة بسيطة.
ربما سيفتحadityapatwardhan و @ SteveL-MSFT خططهما والجدول الزمني خاصة وأن RFC الجديد Help RFC في مرحلة التجربة بالفعل.

وجهة نظري الشخصية هي أنني أفضل رؤية المزيد من وحدات المجتمع تنجح وتصبح معيارًا واقعيًا بدلاً من طلب وحدات "رسمية" من Msft.

iSazonov إنه شيء واحد أن يكون لديك حل يعمل على إجراء تسلسل / إلغاء تسلسل مخطط محدد جيدًا. إنه أمر آخر تمامًا أن يكون لديك حل يعمل بشكل عام مع جميع المخططات المتوافقة مع YAML.

أفهم رغبة MSFT في إعادة استخدام المشاريع المجتمعية لخفض التكاليف. لكن الوضع ، في الواقع ، هو أن MSFT قد لا تستفيد من العديد من المشاريع المجتمعية:

• الكثير منهم لديهم رموز سيئة ، ليس لديهم ثقة
• العديد من المشاريع شخص واحد

نشرت MSFT مواصفات Powershell منذ أكثر من 10 سنوات ، ولكن لم يقم أحد باستدارتها حتى الآن حتى MSFT.
مشروع OpenSSL موجود منذ سنوات عديدة ولكن لم يقم أحد بنقله إلى Windows بينما MSFT لم يفعل ذلك.
كشفت MSFT عن عدة آلاف من واجهات API ، ولكن كم منها تم نقلها إلى Unix؟
الشيء المثير للاهتمام حول سبب إطلاق الشركة لمشروعها NET Core بدلاً من إعادة استخدام Mono؟
PowerShell هو بالفعل عام ونصف مشروع مفتوح المصدر ، لكني أرى أنه في هذا المستودع شخص واحد فقط من المجتمع يقدم مساهمة منهجية في الكود markekraus ويقوم شخص واحد فقط بإجراء تحليل منهجي @ mklement0.
لا أعتقد أنه إذا قسمنا المشروع إلى أجزاء ، فسنحصل على المزيد من المساهمات.
لا أعتقد أن الوضع سيتغير غدًا. لن أعتمد عليه.

markekraus آمل

يضعiSazonov نقاطًا مهمة حول الدعم والثقة والصيانة لوحدات الطرف الثالث. يمكن أن تصبح بعض وحدات الطرف الثالث ناجحة وناضجة مثل Pester.
ومع ذلك ، لا ينبغي للمرء أن يفترض أن وحدة YAML الرائعة ستتطور من تلقاء نفسها خلال السنوات القادمة. الحقيقة هي أن معظم الوحدات يتم نشرها من قبل مؤلفين قاموا بحل مشكلة معينة وقاموا بعمل جيد بنشر الكود الأساسي العام الخاص بهم. هكذا انتهى الأمر بوحدتين تهدفان إلى حل نفس المشكلة. من الناحية المثالية ، قد يحتاج المرء إلى دمجها لتركيز الجهود ، وإلا فإنها ستبتعد أكثر في المستقبل أو ستصبح قديمة وقريباً سيكون هناك المزيد من الوحدات التي ينشرها أشخاص آخرون.
تشير المشكلة الأساسية المتمثلة في وجود محلل مناسب إلى أن العمل الأساسي الأساسي (والجوهري من حيث الجهد) ضروري ومطلوب للحصول على وحدة YAML جيدة.
أنا لست خبيرًا في YAML ، ولكن هل هذه مجرد مشكلة تتعلق بمواصفات اللغة الفضفاضة نفسها أو التفسير المحدد بواسطة أنظمة مختلفة مثل VSTS أو AppVeyor أم أن هذا مجرد عدم وجود محلل جيد؟
لقد وجدت أنه من المحبط كتابة YAML في VSCode وفقط عند تشغيله في VSTS للحصول على خطأ لا يعجبه محلل VSTS ...

بالنسبة لي ، هذه المحادثة هي مثال على مشكلة "تنظيم / هندسة الكود" للمصدر المفتوح.

يوفر المصدر المفتوح أفكارًا جيدة للبذر وقواعد التعليمات البرمجية - ولكن إذا لم يتم منحها نظرة معمارية جادة عند اعتمادها باعتبارها الحل الأكثر عمومية - فهذا يعني 10 سنوات من إصلاحات الأخطاء للعناصر التي كان من الممكن الاعتناء بها في مراجعة التصميم اللائقة .

في الحالات الحقيقية لـ bergmeister "النجاحات الناضجة" ، غالبًا ما يكون عاتقه مهمة تعميم قاعدة الكود. لكن لا يمكن ضمان حدوث ذلك.

أعتقد أن البعض منا يقول "دعم YAML مثل دعم كتابة الملفات - إنه أساسي - يجب أن تتم هندسته بنفس الطريقة => بقصد أن يكون المعيار الذهبي لهذه الوظيفة"

الجمع بين 1) السمة شبه المهندسة للمصدر المفتوح جنبًا إلى جنب مع 2) الطبيعة الأساسية لـ YAML التي يبدو أنها تجعل الكثير منا يحث على اتباع نهج منظم للغاية نعلم أن مطوري Microsoft PowerShell يطبقون على عملهم. ليس بالضرورة أن يكون الانجراف عن كل الأشياء الرائعة الأخرى مفتوحة المصدر يمكن أن يساعدنا بالفعل.

نقاط صالحة للغاية على نضج البرنامج. لم ألق نظرة عن كثب على الوحدتين المدرجتين هنا ، ولا في yamldotnet لإبداء أي رأي. شيء يمكننا النظر إليه عندما نبدأ التخطيط لـ 6.2.0

لا تفهموني خطأ ، فأنا أقدر الخبرة والنهج المنهجي لفريق PowerShell ومطوري MSFT ، أعتقد أنه من الخطأ بالنسبة لهم محاولة سد جميع الثغرات بوحدة نمطية من MSFT مختومة ... لا يتسع (وقد رأينا مشكلة موارد DSC بالفعل).
إن زيادة الاعتماد على الوحدات النمطية المقدمة من MSFT هشة ولا تساعد في نمو المجتمع ولا تنوع النظام البيئي.
أنا أؤيد مساهمة MSFT في مشاريع مفتوحة المصدر لمشاركة خبراتهم والمساعدة في تحسين الممارسات والجودة ، مع عدم الاعتماد عليها (لأنك تعلم ، السناجب ...!).
يعتبر _MSFT كمزود فريد للأشياء المعتمدة_ نموذجًا قديمًا يكافحون بالفعل للتثقيف بشأنه ، ولا يساعد المجتمع على تشجيع هذا النهج (على سبيل المثال ، سأنتظر ، أو أنين ، في Microsoft لعدم حل المشكلة التي لدي_ نوع الموقف في النظام البيئي OSS).

أوافق على أن دعم YAML أساسي ، بدلاً من إعادة كتابة فريق PS من البداية ، فلماذا لا تساعد المشرفين الحاليين على المشاريع على التحسين ، ومنحهم فرصة لدمج المشاريع والاستماع منهم إلى ما يتطلبه الأمر. يشبه إلى حد ما التدريب المهني / الإرشاد من فريق PS على وحدات الوظائف الأساسية.
مجرد إعادة كتابة وحدة جديدة يبدو وكأنه رد فعل مهندس لحل مشكلة ليست مشكلة هندسية. إعادة كتابة وحدة YAML هي مهمة هندسية _ سهلة_ لفريق PS ، ولكنها لن (تساعد) في إصلاح مشكلة نضج المجتمع ، ولن تعطي الحافز الصحيح.
ما إذا كان Yaml هو العنصر الاستراتيجي لمعالجة هذا الأمر هو دعوة MSFT على الرغم من :)

تضمين التغريدة

سأقدم هذا مع عدم كوني خبيرًا في YAML. لقد أجريت بعض الأبحاث حول هذا عندما أردت خبز بعض إعدادات AppVeyor مثل yaml في خط أنابيب franken الخاص بي. نظرت في كيفية قيام عشرات أو نحو ذلك من مشاريع C # باستهلاك YAML. نظرًا لأن مشاريع PowerShell تستخدم YamlDotNet ، لا يمكنني إلا أن أفترض أنها ليست أسهل. على الرغم من أنني قمت على الأقل باللعب مع كل من PSYaml و PowerShell-yaml ونظرت عن كثب إلى عدد قليل من مشاريع PowerShell التي تستخدمها.

أنا لست خبيرًا في YAML ، ولكن هل هذه مجرد مشكلة تتعلق بمواصفات اللغة الفضفاضة نفسها أو التفسير المحدد بواسطة أنظمة مختلفة مثل VSTS أو AppVeyor أم أن هذا مجرد عدم وجود محلل جيد؟

أظن أن طبيعة YAML يمكن قراءتها من قبل البشر على حساب احتمال أن تكون سهلة القراءة بواسطة الآلات. يمتد نموذج قابلية القراءة هذا إلى الطريقة التي يكتب بها مؤلفو YAML ملفات YAML الخاصة بهم. على الرغم من أن YAML الناتج متوافق مع مواصفات YAML ، إلا أنه يتم تحليله بحيث يصبح غير قابل للاستخدام في الكود دون استخدام الكائن غير المتسلسل كوسيط لكائن مفيد بالفعل.

وهذا يعني أن 90٪ من الوقت لا يمثل إلغاء التسلسل من YAML إلى كائن مشكلة ، ولكن تصميم / هندسة البيانات كذلك. ال 10٪ الأخرى من الوقت _ هي تحليل المشكلات التي يمكنني أن أعزوها فقط إلى "YAML يصعب تحليله ، يا رجل". ومع ذلك ، فإن الكائنات التي تم إلغاء تسلسلها غالبًا ما تكون أكثر فائدة من التعبير العادي عما تبحث عنه ....

كمثال ، السلاسل الآمنة في 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 ، فسأضعها على أنها ميزة "يجب أن يكون لديك". إنها فرصة ضائعة خاصة مع إضافة فئات PowerShell في الإصدار الخامس.

IMO ، مجرد إدخال سلاسل YAML في كائن ليس جيدًا بما يكفي. يبدو أن ذلك سهل (90٪ من الوقت على الأقل). الحيلة هي تحويل سلاسل YAML إلى كائنات _مفيدة_. هذا يتطلب بعض المرونة من الحل. ولكن يجب أيضًا أن تكون هذه المرونة ودودة إلى حد ما ولا تتطلب IISResetMe و lzybkr لتقديم نصائح حول التسلسل ....

لهذا الغرض ، لم أر أي شيء يعمل على نطاق عام. تتبنى المشاريع الحلول المتاحة ، ثم تستخدم مخرجاتها كوسطاء لأشياء مفيدة بالفعل (مما يؤدي إلى إعادة اختراع مجموعة من العجلات التي ربما ينبغي تحميصها في المنبع). أو تقلل المشاريع من قابلية قراءة YAML لسهولة التحليل من YAML إلى الكائنات.

تضمين التغريدة

أوافق على أن دعم YAML أساسي ، فبدلاً من إعادة كتابة فريق PS من البداية ، فلماذا لا تساعد المشرفين الحاليين على المشاريع على التحسين ، ومنحهم فرصة لدمج المشاريع والاستماع إلى ما يتطلبه الأمر

اسأل نفسك لماذا بدأت MSFT مشروع .Net Core بدلاً من استمرار Mono بعد سنوات عديدة.

MSFT هو مجتمع أيضًا. وكأي مجتمع لديه نفس مشاكل التفاعل مع المجتمعات الأخرى.

بالنسبة للسياق ، لا أقصد ضمنيًا أن يتم تنفيذ أي عمل من البداية - يمكن اعتماد الكود - ولكن يجب بعد ذلك فحصه من منظور هندسة تطوير الأنظمة قبل تحسينها. يمكن أن يكون مفتوح المصدر بعد تلك المراجعة وإعادة الإصدار.

وجهة نظري هي الحصول على مراجعة معمارية مهمة ومعالجة من فريق يفهم تمامًا الفروق الدقيقة في الكود الأساسي الذي سيتم الاستفادة منه في كل مكان تقريبًا.

نموذج آخر يستحق النظر دائمًا هو الاستحواذ / العقد / الثانية. على هذا الأساس ، يُبذل جهد للوصول إلى شروط تجارية مع واحد أو أكثر من أعضاء المجتمع / الشركات لتوظيف خدماتهم لدورة تطوير مُيسرة / بقيادة MSFT لإعادة تصميم و (بطريقة ما) دمج / توصيل المنتج (المنتجات) . تم ذلك بنجاح مع Xamarin ، التي أطلقت المشروع على Net Foundation ، ورخصت له بموجب MIT ، وتوظيفت / تعاقدت / شاركت في الموارد الرئيسية مثل Miguel de Icaza و Nat Friedman عبر Xamarin. يتذمر البعض من أن هذه خيانة مفتوحة المصدر. لكنها تخلق حوافز إيجابية للأفراد والشركات الصغيرة لتصور وتطوير المشاريع التي يمكن أن تكون لاحقًا مناسبة للتبني والتكامل على نطاق واسع في نظام بيئي رئيسي واحد على الأقل. من المؤكد أنه يُفضل القفز مباشرة إلى قائمة فارغة داخل المنزل تنسخ المفهوم والوظائف بالكامل والعديد من الأفكار ولكنها تتخلص من المبدعين و (ظاهريًا) الشفرة.

iSazonov آسف للرد المتأخر ، لا محلل platyPS yaml ليس جيدًا: إنه يدعم أزواج القيمة الرئيسية فقط. نستخدم أيضًا YamlDotNet لإنشاء yaml هناك.

فيما يتعلق بالمشاعر تجاه إبقاء هذا بعيدًا عن مجموعة الميزات الأساسية: هناك اختلاف كبير جدًا في كيفية تعامل PowerShell مع التبعيات مقارنةً بـ Ruby أو Python أو Node.js.

تحتوي كل لغة من هذه اللغات على أدوات إدارة التبعية (الحزم ، النقطة ، npm / الغزل) التي تجعل إدارة التبعيات الخارجية سهلة ، والأهم من ذلك أنها قابلة للتكرار. إن وجود شيء مثل Gemfile/Gemfile.lock أو package.json/package-lock.json [,yarn.lock] مما يجعل التثبيت السهل لجميع الحزم المطلوبة ويضمن أنك تبقى عند مستوى تصحيح محدد للغاية هو تمييز مهم للغاية ، في رأيي ، ما الذي يجعل مكتبات الطرف الثالث لشيء بهذا الأساس ممكنًا.

ربما يوجد شيء يمكن القيام به مع Nuget لحل هذه المشكلة ، لكنني لم أر مطلقًا أي مقالات تصف استراتيجيات / أنماط إدارة التبعية لـ PowerShell. يعد امتلاك المعرض أمرًا رائعًا ، ولكن إذا كان عليك تثبيت جميع الحزم المطلوبة يدويًا ، فلن يكون ذلك ممكنًا لأي عملية نشر كبيرة.

تعديل:
لذلك يبدو أن ما أبحث عنه قد يكون متاحًا بالفعل: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. سأختبر هذا بمجرد أن تتاح لي لحظة. إذا نجح الأمر ، فسوف أحتاج إلى إعادة النظر في موقفي بشأن ما إذا كان ينبغي أن يكون هذا عنصرًا أساسيًا أم لا. ما زلت أواجه صعوبة في التوفيق بينها وبين حقيقة أن JSON هي وظيفة أساسية ، لكنني أفترض أنها يمكن اعتبارها "القاسم المشترك الأدنى".

bgshacklett يجعل نقطة جيدة للغاية.

@ chuanjiao10 - يرجى التوقف عن تعليق التخريبية عبر العديد من القضايا في هذا المستودع، فإن الحل الصحيح لا يكون لتضمينها في Microsoft.PowerShell.Utility حدة وسفينة إنفاكت بها باعتبارها وحدة منفصلة استضافتها في PowerShellGallery

عندما تقول بشكل أصلي ، هل تقصد مثل XML أو JSON؟

التفكير الحالي هو أنه لا ينبغي دمج YAML في PowerShell على الإطلاق ، بل يجب أن تكون وحدة منفصلة يمكنك تحديثها دون التقاط إصدار جديد من PowerShell.

إذا تم دمج YAML في PowerShell مثل XML ، فسيكون ذلك مستحيلًا (فكر في [xml] "b")

إذا ذهبنا إلى مسار JSON ، فسيكون لديك أوامر cmdlets للعمل مع YAML - لذلك لم يتم خبزها حقًا في PowerShell ، ولكن لا يزال لديك عيوب الحاجة إلى تحديث PowerShell للحصول على تحديثات YAML.

شخصيًا ، بينما يبدو الأمر وكأنه الشيء "الصحيح" في البريد الوارد ، سأقترح أن هذا ليس هو الشيء الصحيح الذي يجب فعله

lzybkr أعلم أننا قلنا إننا لا نريد إحضار مكتبة جديدة ، لكنني أعتقد أن هذا شيء قد نحتاج إلى إعادة تقييمه. من الناحية المثالية ، يجب علينا أيضًا أن نشحن الوحدة في المعرض ، لكنني أعتقد أن طنًا من السيناريوهات الحديثة تتطلب YAML الآن.

ربما ليس في الإطار الزمني 6.0 ، لكن يجب أن نتحدث عنه.

الشحن وحدة خارجية هو أفضل بكثير من وجهة نظري كما يمكن أن يكون المستوى الأدنى المستخدمة وIMO انها أقل المهمة فريق من بوويرشيل على القيام بذلك وأكثر من ذلك المجتمع لدفع هذا بمساعدة من فريق PowerShell لتحصل على جودة عالية كلما كان ذلك ممكنا.

مرة أخرى @ chuanjiao10 تقرر سابقًا عدم وضع YAML Cmdlets في PowerShell Core في # 2109 وتم رفضها بحق في ذلك الوقت حيث يجب أيضًا رفضها الآن أيضًا.

بخصوص

الاتحاد قوة. أمريكي يحتاج إلى سيارة ، هل رأيته يذهب إلى وول مارت لشراء عجلة ، ويذهب إلى أمازون لشراء محرك ، ويجمع بين نفسه (اصنع سيارة)؟

تعتبر مقارنة السيارة بالبرنامج تشبيهًا سيئًا نظرًا لأن المكونات الموجودة في السيارة تأتي من العديد من الموردين المختلفين ثم يتم تجميعها في منتج قابل للاستخدام ، والذي لا يختلف عن وحدات PowerShell التي طورها المجتمع والتي يمكن بعد ذلك مزجها ومطابقتها & المستخدمة في البرامج النصية

بخصوص هذه النقطة

المكتبة الرئيسية مدمجة ، وهذا مهم للغاية ، وإلا أرى أنه يجب وضع convertfrom-json ، و convertto-json ، وما إلى ذلك ، في PowerShellGallery.

لقد دافعت عن هذا لأكبر عدد ممكن من الوحدات المضمنة حسب # 1979 وأود أن أرى PowerShell Core ضعيفًا قدر الإمكان والذي بدأ مناقشته أكثر في # 5681

وإعادة

لا تميز ضد YAML ، لا تملق JSON.

أنا لا أميز Yaml ولا أطعم Json لأن كلاهما له عيوبهما ولكن كلاهما له استخداماتهما ، وإذا كنت قد تمكنت من التأثير على عدم شحن Json cmdlets في PowerShell ، كنت سأفعل الشيء نفسه تمامًا كما أفعل هنا.

أعتقد أنه قد يكون من المفيد إعادة صياغة هذه المناقشة قليلاً. على وجه الخصوص ، هل سيكون أولئك الذين يؤيدون إدراج YAML في اللغة الأساسية على استعداد لإدراج حالات استخدام محددة ولماذا لا تكفي الوحدة النمطية في معرض PowerShell لمعالجة حالة الاستخدام المذكورة؟ في هذه المرحلة ، يمكننا إجراء مناقشة مدفوعة بالمتطلبات وإيجاد حل عملي للمشكلة المطروحة.

حالة الاستخدام الأساسية الخاصة بي هي أتمتة نظام التشغيل ونشر التطبيقات. في حالة واحدة على الأقل ، أريد قراءة ملف YAML الذي دعا البرنامج النصي الخاص بي لفهم المعلمات.
في كثير من الأحيان في هذه الحالات التي يكون فيها الاعتماد على جهة خارجية ، غير تابعة لاتفاقية مستوى الخدمة بالنسبة لنا ، تعتبر الخدمة بمثابة رفض كبير. يمكن أن يؤثر على أنشطة قياس الإنتاج.

هذه هي حالة الاستخدام الخاصة بي للشحن في أكثر البصمة الأساسية لبويرشيل.

أقدر المناقشة الحية ، دعنا نحاول إبقائها حضارية :)

@ PowerShell / بوويرشيل-جنة ناقشت هذا سابقا. نحن نتفق على أن دعم YAML مهم نظرًا لمدى انتشاره اليوم. نريد أيضًا أن نرى المزيد من الوحدات التي نشحنها حاليًا في PSCore6 تم نقلها بحيث تبدأ مع الحد الأدنى من تثبيت PSCore6 ثم إضافة ما تحتاجه (مع الوحدات الوصفية ، لا تحتاج إلى إضافة أكثر من 10 وحدات ، واحدة فقط مقابل DevOps ، على سبيل المثال). فيما يتعلق بـ YAML ، فإن التفكير الحالي هو أن هذه يجب أن تكون وحدة منفصلة (يمكنني إنشاء الريبو ضمن PowerShell org إذا كان أي شخص مستعدًا لبدء عمل النماذج الأولية لهذا ، ففريقي ليس لديه عرض النطاق الترددي الآن). يعد استخدام YamlDotNet (أو مكتبة أخرى تابعة لجهات خارجية) أمرًا جيدًا بمجرد تقييمه من وجهة نظر تقنية أو ترخيص أو دعم (على غرار الطريقة التي اعتمدنا بها على Json.Net). ومع ذلك ، في المرة الأخيرة التي نظرنا فيها إلى YAML و YamlDotNet ، تكمن المشكلة في أن تطبيقات YAML تختلف على نطاق واسع وأن تلك المكتبة لا تدعم كل ما هو موجود (حتى بعض التطبيقات الشائعة).

سأقول فقط أن دعم YAML هو شيء أود أن ينظر فيه الفريق بعد الإصدار 6.2.

@ SteveL-MSFT هل يمكنك التعليق بناءً على المشكلة و https://github.com/dotnet/corefx/issues/34578؟ هل يمكننا استخدام YamlDotNet أو نحتاج إلى واجهة برمجة تطبيقات أكثر موثوقية من CoreFX؟

في رأيي هو السماح لـ convertfrom-json ، convertfrom-jaml بالحالة نفسها ، إما الانتقال للخارج أو المدمج.

لقد كنت أدعو إلى ضرورة نقل JSON cmdlets خارج المشروع. هناك عدد غير قليل من التغييرات التي يرغب الكثيرون في إجرائها والتي ستكون تغييرات متقطعة إلى حد ما ، لكن لا يمكن إجراؤها لأن أوامر cmdlets مرتبطة بـ PowerShell. يتيح لنا إخراجها من المشروع إجراء التغييرات الرئيسية في إصدار رئيسي جديد من وحدة أوامر cmdlets ، وشحن PowerShell بإصدار أقدم يوفر توافقًا مع الإصدارات السابقة مع السماح للمستخدمين بالتحديث إذا رغبوا في ذلك ... ومع ذلك ، فهو كذلك متاعب كبيرة لتضمين وحدات خارجية مثل هذا ، IMO.

أفضل أن نتعلم من أخطائنا مع JSON و Pester بدلاً من معاملة YAML بشكل تعسفي بنفس الطريقة. بالتأكيد لا ينبغي أن يكون جزءًا من وظائف PowerShell الأساسية ، ولكن يجب أن يحتوي بالتأكيد على نوع من الوحدات المدعومة رسميًا مع ملكية مشتركة بين المجتمع وفريق PS.

أحب تلك الفكرة. قد يساعد نقل JSON Cmdlets في إظهار مشكلات سير العمل الموجودة حاليًا مع التبعيات الصلبة على الوحدات الخارجية.

لكن yaml مهم لمسؤولي النظام ومطوري البرامج النصية ، يحتاج هؤلاء المستخدمون إلى أوامر yaml.

قد يحتاجون إليهم ولكن هذا لا يعني أنهم بحاجة إلى أن يتم تضمينهم مباشرة في PowerShell لأن الوحدة الخارجية أكثر من مقبولة ولديها دورة حياة دعم أكثر مرونة من أي شيء تم تجميعه في المستودع الأساسي.

يجب أن أقول إن فكرة @ SteveL-MSFT الخاصة بالوحدة الوصفية DevOps هي الطريقة الصحيحة حقًا لهذا على المدى الطويل حيث يتيح ذلك لمجموعات مختلفة من المستخدمين الحصول على مجموعة أبسط من الحزم التي يسهل إدارتها كثيرًا باعتبارها تبعية خارجية أكثر من كونها اعتمادًا داخليًا ، وهو أمر منطقي جدًا بالنسبة لي للمضي قدمًا ، على الرغم من أنها يجب أن تكون وحدات تعريفية قائمة على مجموعات التكنولوجيا لأنني إذا كنت على النوافذ ولا أستخدم اليانصيب ، فلماذا أحتاج إلى yaml cmdlets على شبابيك؟

في حين أن هناك عددًا كبيرًا من المستخدمين في عالم Linux يستخدمون yml كما هو مذكور من قبل

هل هناك أي شخص يريد أن يصبح مالكًا ويرافق هذه الأوامر cmdlets في مشروع منفصل؟

iSazonov ، يبدو أن corefx غير مهتم حاليًا بدعم YAML المدمج. يبدو أن YamlDotNet هي المكتبة الأكثر شعبية ، وهي مرخصة من معهد ماساتشوستس للتكنولوجيا ، وتتم صيانتها بنشاط ، لذلك سأبدأ من هناك. سيكون المشروع الذي يحركه المجتمع مدهشًا وسيحدث على الأرجح في وقت أقرب مما لو تركته لفريق PowerShell.

@ SteveL-MSFT يبدو أن هذا لسبب وجيه - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255 والذي أتوقع أن هذا قد قلل الثقة في هذه المكتبة بالذات.

يبدو أن شركة corefx غير مهتمة حاليًا بدعم YAML المدمج.

يسأل فريق CoreFX عن حالات الاستخدام. إذا كان مشروع PowerShell سيقول إننا بحاجة إلى API ، فسوف يفكرون في إضافة API.

سيكون المشروع الذي يحركه المجتمع مدهشًا وسيحدث على الأرجح في وقت أقرب مما لو تركته لفريق PowerShell.

أوه ، أنا أعرف مشروعًا واحدًا فقط - Pester. وأنا لا أؤمن بالمشروع الذي يقوده مجتمع yaml - فلماذا لم يظهر في السنوات القليلة الماضية؟
أفكر في بدء المشروع ، لكنني أوقفني أنه لا يمكنني أبدًا الوصول إلى مستوى الجودة والامتثال والأمان للرمز الذي يتطلبه MSFT.
أعتقد أن MSFT لن تكون قادرة على الوثوق بالمشاريع واستخدامها بدون تدقيق أمني.
لدي فكرة واحدة فقط لجعلها تعمل. مشاريع MSFT GitHub مثل CoreFX و PowerShell "مملوكة لـ MSFT" و "مدفوعة من MSFT". يمكن أن يكون نوع المشروع الجديد "مملوكًا لـ MSFT" ، و "مدفوعًا من قبل المجتمع" و "تحت إشراف MSFT". تحت "الإرشاد" أعني تنفيذ البيئة حيث سيكون المشروع موثوقًا به وذات جودة عالية.

تحتاج Microsoft إلى تجميع دعم YAML في العلبة لـ PowerShell Core. واضح وبسيط.

brettjacobson نعم ، سيكون الأمر بسيطًا وبسيطًا وعالي الجودة ولكن فريق MSFT لا يمتلك الكثير من الموارد. هل انت جاهز للمساهمة؟ :-)

brettjacobson - لا تحتاج Microsoft إلى تجميع دعم YAML. قد يكون مفيدًا إذا فعلوا ذلك ولكن لا يوجد أي شرط منهم للقيام بذلك ولا توجد حاجة للقيام بذلك على الإطلاق.

هذا طلب ميزة لشيء كثير want وسيكون في النهاية use ولكنه ليس أمرًا بالغ الأهمية need وبالتالي من غير المحتمل _ الحصول على الأولوية وهو بالضبط ما @ SteveL-MSFT كان يحاول الوصول عندما قال ما يلي

سأقول فقط أن دعم YAML هو شيء أود أن ينظر فيه الفريق بعد الإصدار 6.2.

سيكون المشروع الذي يحركه المجتمع مدهشًا وسيحدث على الأرجح في وقت أقرب مما لو تركته لفريق PowerShell.

فريق PowerShell ليس ضخمًا ، وبالتالي فإن النظر إلى هذه الطريقة الواقعية هو أفضل وأسرع طريقة لتكون قادرًا على الحصول على دعم YAML سيكون خارج مجموعة الميزات الأساسية لـ PowerShell ، بدلاً من أن يصبح مخبوزًا في المنتج نفسه.

يسأل فريق CoreFX عن حالات الاستخدام. إذا كان مشروع PowerShell سيقول إننا بحاجة إلى API ، فسوف يفكرون في إضافة API.

iSazonov IMHO لن يكون هناك دعم YAML مدمج في CoreFX ، حيث لم يكن هناك دعم JSON كامل حتى الآن.

هل ستنتظر مكتبة خارجية "رائعة" أم تطلب من جيمس نيوتن-كينج إنشاء Newtonsoft.Yaml ؟ :-)

NextTurn سنحصل على
يقوم فريق CoreFX دائمًا بإضافة واجهة برمجة تطبيقات جديدة إذا كان هناك طلب كبير من المجتمع. إذا كان هناك العديد من المشاريع التي يمكن أن تستفيد من YAML فسوف يضيفون. حاليا لا توجد مثل هذه الطلبات.

ما الذي لا أفعله مع كل نظام pwsh ؟ أفعل Install-Module -Name powershell-yaml .

مونجو ، كوبيرنيتيس ، إستيو ، أنسبل ، سمها - أنا استخدم. كل هذه هي YAML ولدي قوالب YAML والتحولات. pwsh جيدًا بالنسبة إلى DevOps وهم يتحدثون لغة YAML.

يقترح @ dzmitry-lahoda الإصدار # 5681 أن يكون لديك إصدار "غني" من PowerShell يتم شحنه مع مجموعة من الوحدات النمطية الشائعة مثل Pester ، إلخ. يُرجى النشر في هذه المشكلة ولكن بالنظر إلى أنه يبدو أنه لا يوجد فائز واضح بين وحدتي yaml المتاحتين حاليًا وهما يتشابهان مع بعضهما البعض ، قد يكون قرارًا صعبًا لاختيار مفضل.

أرى YAML واحدًا فقط :(

Pester ، نعم. ثقيل جدًا لشحن إطار عمل BDD إلى الخط الرئيسي ، على عكس قارئ YAML لتطبيقات حاوية pwsh الخاصة بي.

هل تم الانتهاء من هذا الموضوع. ما هي الوحدة الموصى بها (أو المقترحة) لاستخدامها من قبل Microsoft؟
تستخدم خطوط أنابيب DevOps ملف yaml. جميع أتمتة النشر الخاصة بي مبنية باستخدام بوويرشيل. يبدو أن yaml و powerhell لا يلعبان بشكل جيد. هل يعد بوويرشيل خيارًا سيئًا لأتمتة Azure DevOps؟
أحتاج إلى التفكير بعناية في استخدامي / ابتكاري المستقبلي وسوف نقدر بعض التوجيه.
شكرا لك مقدما!

dirkslab يمكنك استخدام https://github.com/cloudbase/powershell-yaml

جيثب

cloudbase / بوويرشيل يامل

PowerShell CmdLets لمعالجة تنسيق YAML. ساهم في تطوير cloudbase / powershell-yaml من خلال إنشاء حساب على GitHub.

شكرًا iSazonov ، هذا هو الحل الذي

لاحظ أن استخدام بوويرشيل يامل تحتاج إلى الموافقة على وحدة غير موثوق بها. هذا هو الجزء الذي أحاول أن أفهمه. توصي Microsoft باستخدام خطوط أنابيب yaml. تقترح Microsoft (أو على الأقل هذا الموضوع) استخدام وحدة الطرف الثالث حتى تتمكن من دمج yaml config مع بوويرشيل ، ولكن لا تؤيد أو توصي بأي منها. كيف تشرح ذلك منطقيا للمؤسسة.
كانت تجربتي حتى الآن هي أنه إذا لم تستخدم الحلول المعتمدة من Microsoft ، فسيؤدي ذلك إلى كتم أي دعم أو تفاهم من Microsoft لمشكلات الحل (لا يهم إذا كان الجزء غير المدعوم يلامس أي شيء يسبب مشاكل). إن مجرد حقيقة أن لديك جزءًا غير مدعوم يؤدي عادةً إلى عدم وجود دعم / مسؤولية.
ربما تغيرت الأمور في عصر المصادر المفتوحة هذا. إن الاستجابة والتوجيهات الرسمية البسيطة من Microsoft ستريحني وتساعدني على الفهم.

نقدر ردك. مع تحياتي.

dirkslab أعتقد أن مدير حساب MSFT الخاص بك هو الشخص المناسب للسؤال عن سياسة الدعم.

يسأل فريق CoreFX عن حالات الاستخدام

من المزايا الواضحة أن yaml موجود في كل مكان حولنا في CI / CD اليوم وعدد أنظمة التكوين ، تتمثل الميزة الإضافية لـ ConvertTo-Yaml في تمثيل HashTable في تنسيق يمكن قراءته من قِبل الإنسان ، على عكس ConvertTo-Json الذي يتعين علينا استخدامه الآن مما يجعل الإخراج غير سهل القراءة.

أستخدم Write-HashTable في هذه الأثناء ، ولكن سيكون من الرائع أن يكون لديك OTB.

أنا أكره yaml ، أنا أكرهه حقًا. ومع ذلك ، هناك جانبان يستحقان دراسة فريق MS:

1. لقد أصبحت اللغة الفعلية لـ CI: docker-compose.yaml ، ansible ، kuber ، k8s ، github ، الدائرة ، اللازوردية ، ... ويبدو أنها تزحف من 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)

إن امتلاك هذه السفينة مع powerhell سيكون تحويليًا في التبشير لمجموعات CI.
"إذا قمنا بالتبديل إلى msowershell ، يمكننا تلقائيًا" -> "أخبرني بالمزيد؟"
ضد
"إذا قمنا بالتبديل إلى msowershell وتنزيل بعض البرامج النصية من المعرض" -> "لا"

1. حقًا ، هذا عرضي ، لكن yaml عبارة عن مجموعة شاملة من json ، مثل أن json هي شكل مختصر من yaml ، محلل yaml الفعال هو محلل json فعال ،

هل يمكن إعادة النظر في هذا لـ 7.1؟ أواجه أيضًا مشكلات في استخدام وحدة نمطية غير موثوق بها وشيء ما لذا يجب أن يكون DevsOpsy أصليًا في PowerShell.

IMHO ، YAML مشهور مثل JSON و CSV ، وعدم وجود محولات علبة الوارد لـ YAML في PowerShell أمر محزن نوعًا ما سيضمن وجود محولات YAML في صندوق الوارد أيضًا أن يكون سلوكهم على قدم المساواة مع محولات JSON ، وهذا ليس هو الحال مع وحدات المجتمع.

لا تفهموني خطأ - أنا أقدر أن الناس ينشئون وحدات للمجتمع ، ولكن في الوضع الحالي للعالم ، يعتبر تحويل YAML رهانات جدولية - لا نتوقع أن يقوم الأشخاص بتنزيل وحدات الطرف الثالث لتحويل JSON.