Powershell: ConvertFrom-Yaml、ConvertTo-Yaml

DSCの観点からも同様の議論がありました。
jsonベースの構成ファイルを変更できるようにするために、テキスト操作コマンドレット内からxmlベースのファイル、YAMLベースのファイル、RegExスワップをサポートするINIベースのファイルを変更するためのオプションが必要でした。

PSに既存のサポートがないということは、そのような能力を得るために一生懸命努力しなければならないことを意味します。
コミュニティからの貢献が出るまで保留されていましたが、PSに組み込むと、DSC部分でもはるかに簡単になります。

ネイティブと言うとき、XMLまたはJSONのような意味ですか？

現在の考え方では、YAMLをPowerShellに組み込むべきではなく、PowerShellの新しいバージョンを取得せずに更新できる別個のモジュールにする必要があります。

YAMLがXMLのようにPowerShellに組み込まれている場合、それは不可能です（[xml] " b "と考えてください）

JSONルートを使用した場合、YAMLを操作するためのコマンドレットがあります。PowerShellに組み込まれているわけではありませんが、YAMLの更新を取得するためにPowerShellを更新する必要があるという欠点があります。

@lzybkr新しいライブラリを持ち込みたくないと言ったのは知っていますが、これは再評価する必要があるかもしれないと思います。 理想的には、モジュールもギャラリーに出荷する必要が

6.0の時間枠ではないかもしれませんが、それについて話し合う必要があります。

@ ArieHein-ハッシュ配列をレジストリに保存および取得する簡単な関数がいくつかあります。 REG_SZのみを処理しますが、単純な設定セットの場合はそれで十分です。コピーが必要な場合はお知らせください。

「ネイティブ」（主に「ビルトイン」を意味します）と言ったとき、私は誤解しました。更新可能なスクリプトモジュールが同梱されていても気になりません。

私たちの最初の議論＃2109

@ iSazonov-ああ、そうだね！

スレッドでのYAMLのAWSサポートへの参照に気づきました-いくつかのテンプレートを変換していて、これが役立つことがわかりました： https ：

@iSazonovポインタをありがとう、私は何らかの理由でそれを見つけることができませんでした。 ただし、よく覚えておいてください。

その元のスレッドを読み直す際には、将来のある時点でコマンドレットを確実に実装し、ギャラリーに出荷する必要があると思います。 それらの品質と人々の認識された有用性に基づいて（6.0.0以降に実行したいリファクタリング作業とともに）、受信トレイとギャラリーのみの呼び出しを行うことができます。

https://github.com/PowerShell/platyPSにYamlがあり

ええ、これは素晴らしいでしょう、変換するためにhttps://github.com/awslabs/aws-cfn-template-flipを使用することになりました

@MattTunny貢献へようこそ！ :-)

投票するために開かれたWindowsServerユーザーの声があります:-)

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

これは間違いなくネイティブPS6.1ライブラリの一部である必要があります。 最近のYAMLには非常に多くのものがあります。

PSGalleryにはpsyamlモジュールとpowershell-yamlモジュールがありますが、どちらもVSTSビルド定義からYAMLファイルをラウンドトリップすることはできません。 モジュールがPowerShellにベイクされているか、PSGalleryのモジュールであるかは関係ありません。

ここでの中心的な問題は、モジュールをデプロイする方法が不格好なことなのだろうか。 今日では、モジュールを使用する前に、モジュールを見つけて信頼し、インストールする必要があります。 これを、Javascriptがvar m = require('mymodule')を実行する（明らかに）巧妙な方法と比較してください。 たぶん、DSCが行うことを実行する方法が必要ですが、ネイティブPowerShellの場合です。 DSCでは、モジュールが構成で参照されると、手動での作業なしで、モジュールが自動的にダウンロードされ、ターゲットノードにインストールされます。 重要であるがコアではないモジュールをそのように利用可能にすると、「コアの一部である必要がある」という議論が排除されます。 また、ネットから切断されているノードの場合、スクリプト内の依存関係をアーカイブにバンドルし、ターゲットにデプロイするツールを使用できます。 これがAzureDSCリソース拡張機能の仕組みです。スクリプトをスキャンして必要なモジュールを特定し、必要なものすべてを含むzipファイルを作成してblobに公開するツールがあります。 次に、Azureリソース拡張機能は、このBLOBをプルし、モジュールをインストールして、スクリプトを実行します。

これほど重要なことについては、ベンダーの方法がない限り、サードパーティのライブラリに依存したくありません。 サードパーティの開発者がエコシステム全体を壊す可能性があるのは簡単すぎます（https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/を参照）。

より広範な問題はさておき、

@bgshacklett Puppetの人たちから聞いたところによると、良いYAMLパーサーはありません:-)

platyPSパーサーで十分ですか？

@vors PowerShellCoreリポジトリでplatyPSYAMLパーサーを再利用する簡単な方法はありますか？

@lzybkrが言うように、PowerShell Galleryに別の公式モジュールを配置するというアイデアを好みます。これは、古いバージョンのPowerShellで使用でき、独自のリリースを持つことができるためです。 これは、 sqlserverモジュールのようなものです。 @BrucePay Microsoft独自のモジュールを備えたPowerShellギャラリーのページであれば、見つけやすく、誰もがそれらを信頼できることを知っているでしょう。

しかし、それがXMLおよびJSONとしてPowershellにバックアップされているかどうかは理解できます。

重要なのは、YAMLは構成ファイルに広く使用されている形式であり、 @ bgshacklettが指摘しているようにサードパーティのモジュールであってはならないため、 ConvertFrom-YAMLとConvertFrom-YAML公式関数が存在することです。

YAMLファイルで動作することがわかった2つのモジュールPSYamlとpowershell-yamlをテストし、比較するブログエントリを作成しました。

内部的には異なるオブジェクトを使用しているため、動作は異なります。

| モジュール| マッピング| シーケンス|
| --------- |：-------------- | ----------- |
| PSYaml | OrderedDictionary | アレイ|
| powershell-yaml | Hastable | リスト|

標準のConvertFrom-YAMLとConvertFrom-YAMLが必要だと思います。

実際には、 ConvertFrom-Yamlでpowershell-yaml用途OrderedDictionaryで変換する際に-orderedパラメータ。
私はこのモジュールをしばらくの間（DSC構成データ用のDatumモジュールで、キッチンyamlで）正常に使用していますが、テストするvstsビルド定義がありません。

それを呼び出す正しい方法は次のとおりであることに注意してください： get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered （人々はしばしば-Raw見逃します）。

なぜMicrosoft_official_モジュールが必要なのか、MSFTにさらに多くのオーバーヘッドをかけ、車輪の再発明を行うのだろうか...おそらく最初に既存のモジュールに貢献しようとし、リグレッションを回避するためのテストを追加し、問題を開いて所有者が問題はより良いアプローチです...
99の既存の実装から標準を作成しようとするとどうなるか知っています...

そして、はい、それは言語の外でより良いでしょう、私は依存関係管理がより良いかもしれないことに同意します、しかしPSですべてをバンドルすることは解決策ではありません。
広範なnpmの問題も、処理の失敗です。 フォークして再公開するとすぐに修正されました。最新バージョンのインターネットからアプリを構築することが、多くのライブアプリを壊した理由でした。

私は@gaelcolasに同意します。これは、既存のコミュニティモジュールの所有者と協力して品質を向上させ、保証するすべての人にとってより良いことだと思います。

このようなプロジェクトのテストには、AppVeyor、Travis CI、VSTS、AWS CloudFormationなどの実世界のYAMLファイルを多数使用する必要があることを付け加えておきます。YAMLの脱滅菌に関する私自身の経験として、私は1つのソリューションが普遍的に機能することでほとんど成功せず、最終的には何度かホイールを再発明する必要がありました。 その意味で、私は@BrucePayに「良いYAMLパーサーはありません」と同意します。

このplatyPSモジュールについて話しているのは、PowerShellヘルプ環境ですでにアクティブに使用されているためです。 行動規範のおかげで、MSFTの誰もこのモジュールがどれほど優れているかを知ることができないと思います。 彼らは黙ってそれを拒否するか、それを改善することができます。
これについてはずっと前に話していましたが、このモジュールのコンポーネントを簡単な方法で使用する方法がわかりません。
たぶん、@ adityapatwardhanと@ SteveL-MSFTは、特に新しいヘルプRFCがすでに実験段階にあるため、計画とタイムラインを開くでしょう。

私の個人的な見解では、Msftの「公式」モジュールを要求するよりも、より多くのコミュニティモジュールが成功し、デファクトスタンダードになることを望んでいます。

@iSazonov明確に定義されたスキーマをシリアル化/逆シリアル化するために機能するソリューションがあることは1つのことです。 YAMLに準拠しているすべてのスキーマで一般的に機能するソリューションを持つことはまったく別のことです。

コミュニティプロジェクトを再利用してコストを削減したいというMSFTの要望を理解しています。 しかし、実際には、MSFTはそれほど多くのコミュニティプロジェクトを利用していない可能性があります。

• 多くは悪いコードを持っていて、信頼を持っていません
• 多くのプロジェクトは一人です

MSFTは10年以上前にPowershell仕様を公開しましたが、MSFTが公開するまで誰もまだ移植していません。
OpenSSLプロジェクトは長年存在していましたが、MSFTがこれを行っていない間、誰もそれをWindowsに移植しませんでした。
MSFTは何千ものAPIインターフェースを明らかにしましたが、そのうちのいくつがUnixに移植されましたか？
なぜ会社がMonoを再利用するのではなくプロジェクト.NetCoreを立ち上げたのかについて興味深いことはありますか？
PowerShellはすでに1年半がオープンソースプロジェクトですが、このリポジトリでは、コミュニティの1人だけがコード@markekrausで体系的に貢献し、1人だけが体系的な分析@ mklement0を行っていることがわかります。
プロジェクトをいくつかの部分に分ければ、もっと貢献できるとは思いません。
明日は状況が変わるとは思いません。 私はそれを当てにしません。

@markekraushttp：//yaml.org/spec/1.2/spec.html#id2802346で非常に期待しています:-)

@iSazonovは、サードパーティモジュールのサポート、信頼、およびメンテナンスについて重要なポイントを示しています。 一部のサードパーティモジュールは、Pesterなどのように成功し、成熟する可能性があります。
ただし、優れたYAMLモジュールが今後数年間で独自に進化すると想定するべきではありません。 現実には、ほとんどのモジュールは、特定の問題を解決し、一般的な基本コードを公開するという善行を行った作成者によって公開されています。 これが、同じ問題を解決することを目的とした2つのモジュールにたどり着いた方法です。 理想的には、努力を集中するためにそれらをマージする必要があります。そうしないと、将来さらにバラバラになるか、単に古くなり、すぐに他の人によって公開されるモジュールが増えるでしょう。
適切なパーサーを使用することの根本的な問題は、基本的な（そして労力の点で実質的な）地上作業が必要であり、優れたYAMLモジュールを使用する必要があることを示しています。
私はYAMLの専門家ではありませんが、これは言語仕様自体の緩みの問題なのか、VSTSやAppVeyorなどのさまざまなシステムによる特定の解釈の問題なのか。
YAMLをVSCodeで記述し、それをVSTSで実行した場合にのみ、VSTSパーサーがYAMLを気に入らないというエラーが発生するのはイライラします...

私にとって、この会話は、オープンソースの「コードキュレーション/アーキテクチャ」の問題の好例です。

オープンソースは優れたシードのアイデアとコードベースを提供しますが、最も一般的なソリューションとして採用されたときに真剣なアーキテクチャの目が与えられない場合は、適切な設計レビューで対処できた可能性のあるアイテムの10年間のバグ修正です。 。

@bergmeisterの「成熟した成功」の真のケースでは、コードベースを一般化するという使命を引き受けたのは、多くの場合、アクティブなメンテナです。 しかし、それが起こることを保証することはできません。

私たちの中には、「YAMLサポートはファイル書き込みのサポートのようなものです-それはコアです-それは同じように設計されるべきです=>その機能のゴールドスタンダードになることを意図して」と言っている人もいると思います

1）オープンソースの半アーキテクチャ化された属性と2）YAMLのコアな性質の組み合わせにより、MicrosoftPowerShell開発者が自分の作業に適用することがわかっている高度にアーキテクチャ化されたアプローチを強く求めているようです。 それは必ずしもオープンソースが実際に私たちを助けることができる他のすべてのクールなものからの漂流ではありません。

ソフトウェアの成熟度に関する非常に有効なポイント。 ここにリストされている2つのモジュールや、yamldotnetを詳しく調べて意見を述べたことはありません。 6.2.0の計画を開始するときに見ることができるもの

誤解しないでください。PowerShellチームとMSFT開発者の経験と体系的なアプローチを大切にしています。彼らが、独自のスタンプ付きMSFTのモジュールですべてのギャップを埋めようとするのは間違っていると思います...スケーリングではありません（DSCリソースの問題はすでに発生しています）。
MSFTが提供するモジュールへの依存度を高めることは脆弱であり、コミュニティの成長やエコシステムの多様性の向上には役立ちません。
私はMSFTがオープンソースプロジェクトに貢献して、彼らの経験を共有し、実践と品質の向上を支援する一方で、それらへの依存を生み出さないことに賛成です（あなたが知っているので、リス...！）。
_承認されたもののユニークなプロバイダーとしてのMSFT_は、彼らがすでに教育に苦労している古いモデルであり、コミュニティがこのアプローチを奨励するのに役立っていません（つまり、_私が抱えている問題を解決しないためにマイクロソフトで待つか、うめき声​​を上げます_ OSSエコシステムにおける一種の態度）。

PSチームが最初から書き直すのではなく、YAMLサポートがコアであることに同意します。プロジェクトの既存のメンテナが改善するのを助け、プロジェクトをマージして、何が必要かを聞く機会を与えてはどうでしょうか。 コア機能モジュールに関するPSチームの見習い/メンターシップに少し似ています。
新しいモジュールを書き直すだけで、エンジニアリングの問題ではない問題を解決するためのエンジニアの反応のように聞こえます。 YAMLモジュールの書き直しは、PSチームにとって_簡単な_エンジニアリングタスクですが、コミュニティの成熟度の問題を修正したり、適切なインセンティブを与えたりすることはありません。
Yamlがこれに取り組むための戦略的アイテムであるかどうかはMSFTの呼びかけです:)

@bergmeister

私はYAMLの専門家ではない自分でこれを前置きします。 yaml構成のようなAppVeyorを自分のfranken-pipelineに焼き付けたいと思ったときに、たまたまこれについて調査しました。 十数個の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コマンドレットで使用できる機能ではありませんが、実際に追加したいと思います。 「公式の」YAMLモジュール/コマンドレットで発言権がある場合は、「必須」機能としてそれを置きます。 特にv5にPowerShellクラスが追加されているため、これは機会を逃しています。

IMO、YAML文字列をオブジェクトに取り込むだけでは十分ではありません。 それは簡単なようです（少なくとも90％の時間）。 秘訣は、YAML文字列を_useful_オブジェクトに取り込むことです。 それには、ソリューションにある程度の柔軟性が必要です。 しかし、その柔軟性もある程度親しみやすく、シリアル化のアドバイスを提供するために@IISResetMeと@lzybkrを必要としない必要があります。

そのため、一般的なスコープで機能するものは見たことがありません。 プロジェクトは利用可能なソリューションを採用し、その出力を実際に有用なオブジェクトの仲介として使用します（おそらく上流で焼き付けられるべき車輪の再発明の束につながります）。 または、プロジェクトはYAMLからオブジェクトへの解析を容易にするためにYAMLの可読性を妥協します。

@gaelcolas

PSチームが最初から書き直すのではなく、YAMLサポートがコアであることに同意します。プロジェクトの既存のメンテナが改善するのを助け、プロジェクトをマージして、何が必要かを聞く機会を与えてはどうでしょうか。

MSFTが何年も後にMonoを継続するのではなく、.NetCoreプロジェクトを開始した理由を自問してみてください。

MSFTもコミュニティです。 そして、どのコミュニティも他のコミュニティとの相互作用の同じ問題を抱えています。

コンテキストとして、私は作業を最初から行うことを意味していません-コードを採用することができます-しかし、改善する前に、システム開発アーキテクチャの観点から精査する必要があります。 そのレビューと再リリースの後、オープンソース

私のポイントは、事実上どこでも活用されるコアコードのニュアンスを完全に理解しているチームから、重要なアーキテクチャのレビューと修正を行うことです。

常に検討する価値のある別のモデルは、取得/契約/秒です。 これに基づいて、1人以上のコミュニティメンバー/企業と商取引条件に到達し、MSFT主導/促進開発サイクルのサービスを募集して、製品を刷新し、（何らかの方法で）統合/接続するように努めています。 。 これは、プロジェクトをNet Foundationにキックし、MITの下でライセンスを取得し、Xamarinを介してMiguel deIcazaやNatFriedmanなどの主要なリソースを採用/契約/関与したXamarinで成功しました。 これはオープンソースの反逆罪だと嘆く人もいます。 しかし、それは、人々や中小企業が、後で少なくとも1つの主要なエコシステムへの広範な採用と統合に適したプロジェクトを考案し、開発するための前向きなインセンティブを生み出します。 確かに、コンセプトと機能全体、および多くのアイデアをコピーするが、作成者と（表面上は）コードを放棄する、白紙の状態の社内やり直しに直接ジャンプすることをお勧めします。

@iSazonov返信が遅れて申し訳ありませんが、platyPSyamlパーサーは良くありません。キーと値のペアのみをサポートします。 また、YamlDotNetを使用してそこでyamlを生成します。

これをコア機能セットから除外することに対する感情について：Ruby、Python、Node.jsなどと比較して、PowerShellが依存関係を処理する方法には非常に大きな違いがあります。

これらの各言語には、依存関係管理ツール（bundler、pip、npm / yarn）があり、外部依存関係の管理を簡単にし、さらに重要なことに、再現可能にします。 Gemfile/Gemfile.lockやpackage.json/package-lock.json [,yarn.lock]ものを使用すると、必要なすべてのパッケージを簡単にインストールでき、非常に特定のパッチレベルにとどまることができます。これは、私の意見では非常に重要な違いです。何がサードパーティのライブラリをこの基本的な実現可能にするのか。

この問題を解決するためにNugetで実行できることがあるかもしれませんが、PowerShellの依存関係管理戦略/パターンについて説明している記事は見たことがありません。 ギャラリーがあることは素晴らしいことですが、必要なすべてのパッケージを手動でインストールする必要がある場合、重要な展開では実行不可能になります。

編集：
したがって、私が探しているものはすでに利用可能であるようです： https ：//docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency

@bgshacklettは非常に良い点です。

@ chuanjiao10 -このリポジトリ内の問題の多く全体の破壊的なコメントはおやめください、正しい解決策は、それらを含めることではないでしょうMicrosoft.PowerShell.Utility別のモジュールがPowerShellGalleryでホストされているとして、それらのモジュールとInfactは船

ネイティブと言うとき、XMLまたはJSONのような意味ですか？

現在の考え方では、YAMLをPowerShellに組み込むべきではなく、PowerShellの新しいバージョンを取得せずに更新できる別個のモジュールにする必要があります。

YAMLがXMLのようにPowerShellに組み込まれている場合、それは不可能です（[xml] "b"と考えてください）

JSONルートを使用した場合、YAMLを操作するためのコマンドレットがあります。PowerShellに組み込まれているわけではありませんが、YAMLの更新を取得するためにPowerShellを更新する必要があるという欠点があります。

個人的には、これは受信トレイにとって「正しい」ことのように感じますが、実際には正しいことではないことをお勧めします

@lzybkr新しいライブラリを持ち込みたくないと言ったのは知っていますが、これは再評価する必要があるかもしれないと思います。 理想的には、モジュールをギャラリーに出荷する必要がありますが、現代のシナリオの多くはYAMLを必要としていると思います。

6.0の時間枠ではないかもしれませんが、それについて話し合う必要があります。

私の見解では、外部モジュールの出荷はダウンレベルで使用できるため、はるかに優れています。IMOは、これを行うPowerShellのチームの仕事ではなく、PowerShellチームの助けを借りてこれを推進するコミュニティを増やし、可能な場合は高品質を実現します。

再び@ chuanjiao10は、＃2109でYAMLコマンドレットをPowerShell Coreに配置しないことが以前に決定されていましたが、今も

に関して

団結は力です。 車が必要なアメリカ人は、彼がウォルマートに行ってホイールを購入し、アマゾンに行ってエンジンを購入し、自分で組み立てる（車をDIYする）のを見たことがありますか？

車とソフトウェアの比較は、車のコンポーネントがさまざまなサプライヤから提供され、使用可能な製品にパッケージ化されていることを考えると、ちょっと悪い例えです。これは、コミュニティによって開発されたPowerShellモジュールと同じで、混合して一致させることができます。スクリプトで使用

この点について

メインライブラリが組み込まれています。これは非常に重要です。そうでない場合は、convertfrom-json、convertto-jsonなどもPowerShellGalleryに配置する必要があります。

私はこれを＃1979に従って可能な限り多くの組み込みモジュールに対して提唱し、PowerShell Coreを可能な限りスリムにすることを望んでいます。これについては、＃5681でさらに説明し始めています。

と再

YAMLを差別したり、JSONをフラットにしたりしないでください。

YamlもJsonもお世辞ではありません。どちらにも欠陥がありますが、どちらにも用途があります。PowerShellでJsonコマンドレットを出荷しないように影響を与えることができれば、ここで行っているのとまったく同じことを行うことができます。

この議論を少し再構成することは有益かもしれないと思います。 特に、コア言語に含まれるYAMLを支持する人々は、特定のユースケースを喜んでリストし、PowerShellギャラリーのモジュールがそのユースケースに対処するには不十分である理由を教えてください。 その時点で、要件主導の議論を行い、目前の問題に対する実行可能な解決策を見つける可能性があります。

私の主なユースケースは、オペレーティングシステムとアプリケーションの展開の両方のベアメタル自動化です。 少なくとも1つのケースでは、パラメーターを理解するためにスクリプトを呼び出したYAMLファイルを読み取りたいと思います。
多くの場合、これらのケースでは、外部の非SLAに依存しているため、サービスは非常に重要です。 これは、本番スケーリングアクティビティに影響を与える可能性があります。

これは、PowerShellコアの最も基本的なフットプリントで出荷するための私のユースケースです。

私は活発な議論に感謝します、それを礼儀正しく保つようにしましょう:)

@ PowerShell / powershell-committeeは、これについて以前に議論しました。 今日のYAMLの普及を考えると、YAMLのサポートが重要であることに同意します。 また、PSCore6で現在出荷しているモジュールをさらに移動して、PSCore6の最小限のインストールから始めて、必要なものを追加することも望んでいます（メタモジュールを使用すると、10以上のモジュールを追加する必要はなく、 DevOps 1つだけ追加できます）たとえば、

YAMLサポートは、チームに6.2以降のリリースを調査してもらいたいものです。

@ SteveL-MSFT問題とhttps://github.com/dotnet/corefx/issues/34578に基づいてコメントして

in.myの意見では、convertfrom-jsonとconvertfrom-jamlのステータスを同じにし、移動するか組み込みにするかを指定します。

私は、JSONコマンドレットをプロジェクトから移動する必要があることを提唱してきました。 多くの人が行いたい変更はかなり多く、かなり大きな変更になりますが、コマンドレットがPowerShellに関連付けられているため、変更を加えることはできません。 それらをプロジェクトから移動すると、コマンドレットモジュールの新しいメジャーバージョンに大きな変更を加えることができ、PowerShellには下位互換性を提供する古いバージョンが付属していますが、ユーザーは必要に応じて更新できます。このような外部モジュール、IMOを含めるのは非常に面倒です。

YAMLを恣意的に同じように扱うよりも、JSONとPesterの間違いから学ぶほうがいいです。 これは、PowerShellのコア機能の一部ではないはずですが、コミュニティとPSチームの間で所有権を共有する公式にサポートされているモジュールを確実に持つ必要があります。

私はその考えが好きです。 JSONコマンドレットを移動すると、外部モジュールへの強い依存関係で現在存在するワークフローの問題を明らかにするのに役立ちます。

しかし、yamlはシステム管理者、スクリプト開発者にとって重要です。これらのユーザーにはyamlコマンドが必要です。

それらが必要になる

@ SteveL- DevOpsメタモジュールのMSFTのアイデアは、長期的には本当に正しい方法であると言わなければなりません。これにより、さまざまなユーザーセットが、はるかに管理しやすいシンプルなパッケージセットを取得できるようになります内部依存よりも外部依存として、これは私にとって将来的には非常に理にかなっていますが、私がWindowsを使用していて、anisbleを使用していない場合、なぜyamlコマンドレットが必要になるので、技術スタックに基づくメタモジュールである必要がありますウィンドウズ？

@ chuanjiao10で述べたようにLinuxの世界にはymlを使用するユーザーが多数いますが、Windowsの世界ではそうではありません。私の理解では、PowerShellの全体的な使用は、システムに受信されているため、PowerShell5.1に固執しています。 、YamlコマンドレットをバンドルするとLinuxユーザーに役立つかもしれませんが、Windowsユーザーには不要な追加のバンドルアイテムのように感じますが、両方のユーザーセットを同じように扱うことは、両方のユーザーセットの外部モジュールになることを意味します。必要に応じて利用できます

所有者になり、別のプロジェクトでこれらのコマンドレットに同行したい人はいますか？

@iSazonov現在、corefxは組み込みのYAMLサポートに関心がないようです。 YamlDotNetは最も人気のあるライブラリのようで、MITライセンスがあり、積極的に保守されているので、そこから始めます。 コミュニティ主導のプロジェクトは素晴らしいものであり、PowerShellチームに任せた場合よりも早く発生する可能性があります。

- @ SteveL-MSFTが良い理由のためのthatsのようだhttps://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255私はこれが、この特定のライブラリの信頼を低下させていることを期待しています。

corefxは現在組み込みのYAMLサポートに関心がないようです。

CoreFXチームがユースケースについて質問します。 PowerShellプロジェクトがAPIが必要であると言う場合、APIの追加を検討します。

コミュニティ主導のプロジェクトは素晴らしいものであり、PowerShellチームに任せた場合よりも早く発生する可能性があります。

ああ、私はそのようなプロジェクトを1つだけ知っています-ペスター。 そして、私はyamlコミュニティ主導のプロジェクトを信じていません-なぜ過去数年間に登場しなかったのですか？
プロジェクトを開始することを検討していますが、MSFTが必要とするコードの品質、コンプライアンス、およびセキュリティのレベルに到達できないことがわかりました。
MSFTは、セキュリティ監査なしではプロジェクトを信頼して使用することはできないと思います。
私はそれを機能させるための唯一のアイデアを持っています。 CoreFXやPowerShellなどのMSFTGitHubプロジェクトは、「MSFTが所有」し、「MSFTが主導」しています。 新しいプロジェクトタイプは、「MSFTが所有」、「コミュニティが主導」、「MSFTが指導」することができます。 「メンター」とは、プロジェクトが信頼され、高品質となる環境の実装を意味します。

Microsoftは、PowerShellCoreの受信トレイにYAMLサポートをバンドルする必要があります。 簡潔でシンプル。

@brettjacobsonはい、

@ brettjacobson -MicrosoftはYAMLサポートをバンドルする必要はありません。 彼らがそうした場合、それは役に立つかもしれませんが、そうする必要はなく、そうする必要もまったくありません。

これは、多くのwant 、最終的にはuseになるものに対する機能要求ですが、重要なneedはないため、優先順位が付けられる可能性はほとんどありません。これはまさに@ SteveL-MSFTです。彼が次のように言ったときに取得しようとしていました

YAMLサポートは、チームに6.2以降のリリースを調査してもらいたいものです。

コミュニティ主導のプロジェクトは素晴らしいものであり、PowerShellチームに任せた場合よりも早く発生する可能性があります。

PowerShellチームはそれほど大きくないため、YAMLのサポートを取得するための最善かつ最速の方法は、製品自体に組み込まれるのではなく、PowerShellのコア機能セットの外部にあることです。

CoreFXチームがユースケースについて質問します。 PowerShellプロジェクトがAPIが必要であると言う場合、APIの追加を検討します。

@iSazonov IMHOは、完全なJSONサポートがまだ行われていないため、CoreFXに組み込みのYAMLサポートが組み込まれることはありません。

では、「すばらしい」サードパーティライブラリを待つのか、それともJames Newton-KingにNewtonsoft.Yaml作成を依頼するのでしょうか。 :-)

@NextTurn .Net Core 3.0で新しいJson（非常に高速（Newton.Jsonより高速）で非常に柔軟）の実装を取得します。
コミュニティからの素晴らしいリクエストがある場合、CoreFXチームは常に新しいAPIを追加します。 YAMLの恩恵を受けることができるプロジェクトがたくさんある場合は、追加します。 現在、そのような要求はありません。

新しいpwshシステムごとに何をしませんか？ 私はInstall-Module -Name powershell-yamlます。

Mongo、Kubernetes、Istio、Ansible、名前を付けてください-私は使用しています。 これらはすべてYAMLであり、YAMLテンプレートと変換があります。 pwshはDevOpsに適しているようで、YAMLを話します。

@ dzmitry-lahoda Issue＃5681は、 Pesterなどの一般的なモジュールのセットが付属するPowerShellの「リッチ」バージョンを提案しています。この号に投稿してください。現在利用可能な2つのyamlモジュールの間で明確な勝者があり、それらはお互いを混乱させています。お気に入りを選ぶのは難しい決断かもしれません。

YAMLが1つだけ表示されます:(

Pester 、ええ。 私のpwshコンテナアプリケーション用のYAMLリーダーとは異なり、BDDフレームワークをメインラインに出荷するには重すぎます。

このスレッドは終了しましたか。 Microsoftが使用する推奨（または推奨）モジュールは何ですか？
DevOpsパイプラインはyamlを使用します。 私のデプロイメントの自動化はすべて、PowerShellで構築されています。 yamlとpowershellはうまく機能しないようです。 PowerShellはAzureDevOpsの自動化にとって悪い選択ですか？
私の将来の使用/革新について慎重に考える必要があり、いくつかの方向性をいただければ幸いです。
前もって感謝します！

@dirkslabhttps ： ます

GitHub

cloudbase / powershell-yaml

YAMLフォーマット操作用のPowerShellCmdLets。 GitHubでアカウントを作成して、cloudbase / powershell-yamlの開発に貢献します。

@iSazonovに感謝し

powershell-yamlを使用すると、信頼できないモジュールをOKする必要があることに注意してください。 これは私が理解するために戦っている部分です。 Microsoftはyamlパイプラインの使用を推奨しています。 Microsoft（または少なくともこのスレッド）は、yaml configをpowershellと統合できるように、サードパーティのモジュールを使用することをお勧めしますが、推奨または推奨しないでください。 それを論理的に企業にどのように説明しますか。
これまでの私の経験では、Microsoftが承認したソリューションを使用しないと、ソリューションの問題に対するMicrosoftからのサポートや理解が失われます（サポートされていない部分が問題の原因となるものに触れても問題ありません）。 サポートされていない部分があるという単なる事実は、通常、サポート/責任をもたらしません。
たぶん、このオープンソースの時代に物事は変わったでしょう。 マイクロソフトからの簡単な公式の対応とガイダンスは、私を安心させ、理解するのに役立ちます。

あなたの応答に感謝します。 よろしく。

@dirkslabあなたのMSFTアカウントマネージャーは、サポートポリシーについて質問するのにふさわしい人物だと思います。

CoreFXチームがユースケースについて質問する

yamlが今日のCI / CDと多くの構成システムで私たちの周りにあるという明らかな利点から、ConvertTo-Yamlの追加の利点は、現在使用しなければならないConvertTo-Jsonとは異なり、人間が読める形式で

その間、 Write-HashTableを使用しますが、OTBがあればこれは素晴らしいことです。

私はyamlが嫌いです、私は本当にそれが嫌いです。 ただし、MSチームが検討する価値のある側面がいくつかあります。

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)

この船にPowerShellを搭載することは、CIグループへの伝道において変革をもたらすでしょう。
「mspowershellに切り替えると、自動的に実行できます」->「詳しく教えてください」
vs
「mspowershellに切り替えて、ギャラリーからいくつかのスクリプトをダウンロードした場合」->「いいえ」

1. 実際、これはバイバイバイですが、yamlはjsonのスーパーセットであり、jsonはyamlの省略形であり、効率的なyamlパーサーは効率的なjsonパーサーです。

これは7.1で再検討できますか？ 信頼できないモジュールなどの使用にも問題があるため、DevsOpsyは実際にはPowerShellにネイティブである必要があります。

IMHO、YAMLはJSONやCSVと同じくらい人気があり、PowerShellにYAMLの受信トレイコンバーターがないのはちょっと悲しいことです。 受信トレイのYAMLコンバーターを使用すると、コミュニティモジュールの場合とは異なり、JSONコンバーターと同等の動作が保証されます。

誤解しないでください-人々がコミュニティ用のモジュールを作成していることを感謝しますが、現在の世界では、YAML変換はテーブルの賭けです-人々がJSON変換用のサードパーティモジュールをダウンロードすることは期待していません。