Powershell: ConvertFrom-Yaml，ConvertTo-Yaml

从DSC方面，我们进行了类似的讨论，
允许我们更改基于json的配置文件，我们希望有一些选项可用于修改基于xml的文件，基于YAML的文件，基于INI的文件，这些文本可从Text Manipulation cmdlet中支持RegEx交换。

PS中缺乏现有的支持意味着我们必须努力获得这种能力。
它一直处于等待社区贡献的状态，但是如果将其烘焙到PS中，那么DSC部分也将变得更加容易。

当您用母语说的时候，您是指XML还是JSON？

当前的想法是，YAML根本不应该包含在PowerShell中，而应该是一个单独的模块，您可以在不使用新版PowerShell的情况下对其进行更新。

如果将YAML像XML一样嵌入到PowerShell中，那将是不可能的（请考虑[xml]“ b ”）

如果我们采用JSON路线，则将有cmdlet与YAML一起使用-因此并没有真正融入PowerShell中，但是仍然存在需要更新PowerShell来获取YAML更新的缺点。

@lzybkr我知道我们说过我们不想引入一个新的图书馆，但是我认为这是我们可能需要重新评估的事情。 理想情况下，我们也应该在Gallery上发布该模块，但是我认为现在有很多现代方案都需要YAML。

也许不在6.0时间范围内，但是我们应该谈论它。

@ArieHein-我有一些简单的函数可以将哈希数组保存和检索到注册表。 仅处理REG_SZ-但是对于一组简单的设置就足够了-让我知道是否要复制。

当我说“本地”时，我打错了话-我的主要意思是“内置”-如果它们是可以更新的内置脚本模块，也不会打扰我。

我们的第一个讨论＃2109

@iSazonov-啊，我明白了！

我注意到在线程上对YAML的AWS支持的引用-我一直在转换一些模板，发现这对您有所帮助： https :

@iSazonov感谢您的

在重新阅读该原始线程时，我认为我们绝对应该在将来的某个时候实现这些cmdlet，并将其发送到Gallery中。 根据它们的质量和人们的感知有用性（以及我们希望在6.0.0之后进行的一些重构工作），我们可以进行直接调用与仅画廊调用。

我们在https://github.com/PowerShell/platyPS中有Yaml

是的，这真棒，最终使用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有很多事情。

现在，PSGallery上有psyaml和powershell-yaml模块，但是两者都无法从VSTS构建定义中往返YAML文件。 我不介意该模块是烘焙到PowerShell中还是PSGallery中的模块。

我想知道这里的核心问题是否是我们部署模块的笨拙方式。 今天，您必须先找到，信任和安装模块，然后才能使用它。 与此相比，（显然）Javascript执行var m = require('mymodule')巧妙方式。 也许我们应该有一些方法可以完成DSC的工作，但对于本机PowerShell。 在DSC中，在配置中引用模块时，无需手动即可自动将其下载并安装到目标节点上。 以这种方式提供关键但非核心的模块应该消除“它应该是核心的一部分”的论点。 对于与网络断开连接的节点，我们可以使用一个工具将脚本中的依赖项捆绑到存档中，然后将其部署到目标。 这就是Azure DSC资源扩展的工作方式-有一个工具可以扫描脚本以找出所需的模块，然后构建一个包含所需内容的zip文件并将其发布到Blob。 然后，Azure资源扩展会拉出该blob，安装模块并运行脚本。

对于如此重要​​的事情，我真的不希望依赖第三方库，除非我有某种出售它的方法。 对于第三方开发人员来说，破坏潜在的整个生态系统太容易了（请参阅https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/）。

除了更广泛的问题外，如@bergmeister指出的那样，PowerShell目前还没有好的YAML模块。 对于高度专注于自动化的语言，这是必须的。 基于YAML的配置文件现在非常流行，即使您不必与团队意见抗衡，也很难避免使用它们。 考虑将XML和JSON作为语言核心部分的背后原因。 YAML的情况确实没有什么不同。

@bgshacklett从我从伪人那里听到的消息来看，没有好的YAML解析器:-)

platyPS解析器足够好吗？

@vors是否有简单的方法可以在PowerShell Core存储库中重用platyPS YAML解析器？

我喜欢在PowerShell画廊中使用@lzybkr这样的单独官方模块的想法，因为可以在较旧的Powershell版本中使用它，并且它可以有自己的发行版。 那就像sqlserver模块。 @BrucePay如果它是PowerShell画廊中包含Microsoft自己模块的页面，则将更容易找到，而且每个人都知道他们可以信任它们。

但是我会理解它是否以XML和JSON的形式备份到Powershell中。

重要的是，它具有ConvertFrom-YAML和ConvertFrom-YAML官方功能，因为@AML是

我进行了博客条目测试，并比较了我发现可用于YAML文件的两个模块： PSYaml和powershell-yaml 。

它们具有不同的行为，因为内部使用的是不同的对象：

| 模块| 映射| 序列|
| --------- |：-------------- | ----------- |
| PSYaml | OrderedDictionary | 数组|
| powershell-yaml | Hastable | 列表|

我认为我们需要一个标准的ConvertFrom-YAML和ConvertFrom-YAML 。

实际上，在使用-ordered参数进行转换时， powershell-yaml ConvertFrom-Yaml使用OrderedDictionary 。
我已经成功使用了该模块一段时间（在用于DSC配置数据的Datum模块中，以及在厨房yamls中），但是没有可测试的vsts构建定义。

请记住，正确的调用方式是： get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered （人们经常会错过-Raw ）。

我想知道为什么我们需要一个Microsoft的_official_模块，在MSFT上增加更多的开销并重新发明轮子……也许首先尝试对现有的模型做出贡献，添加测试以避免回归，并公开问题以确保所有者知道问题是更好的方法...
您知道尝试在99个现有实现中创建标准时会发生什么...

是的，这在语言之外会更好，我同意依赖管理会更好，尽管将PS中的所有内容捆绑在一起并不是解决方案。
广泛的npm问题也是过程失败。 Fork并重新发布后很快就解决了它，使用最新版本的Internet构建应用程序是破坏了这么多实时应用程序的原因。

我同意@gaelcolas的观点，我认为与每个与现有社区模块的所有者合作以提高并确保质量的人都更好。

我只是补充说，针对此类项目的测试应包括使用大量真实世界的YAML文件处理AppVeyor，Travis CI，VSTS，AWS CloudFormation等。对于YAML反序列化的我自己的经验，一种解决方案无法普遍运作，但收效甚微，最终不得不重新发明轮子。 从这个意义上说，我同意@BrucePay的观点， “那里没有很好的YAML解析器”。

我们正在谈论这个platyPS模块，因为它已经在PowerShell帮助环境中被积极使用。 我想MSFT的任何人都不会因为行为准则而知道这个模块有多好。 他们可以默默拒绝它，也可以改进它。
尽管很久以前我们一直在谈论这个问题，但我看不到如何在此简单地使用此模块的组件。
也许@adityapatwardhan和@ SteveL-MSFT将打开他们的计划和时间表，特别是因为新的帮助RFC已经处于实验阶段。

我个人的观点是，我希望看到更多的社区模块能够成功并成为事实上的标准，而不是需要Msft的“官方”模块。

@iSazonov拥有一种解决方案，可以对定义良好的方案进行序列化/反序列化是一回事。 拥有一个可以与所有符合YAML的架构通用的解决方案是另一回事。

我了解MSFT希望重用社区项目以削减成本。 但是实际上，情况是MSFT可能没有利用很多社区项目：

• 许多人的代码不好，不信任
• 许多项目是一个人

MSFT早在10年前就发布了Powershell规范，但是直到MSFT发布之前，还没有人移植它。
OpenSSL项目已经存在了很多年，但是没有人将其移植到Windows，而MSFT却没有这样做。
MSFT揭示了成千上万的API接口，但是有多少接口移植到了Unix？
关于公司为何启动其项目.Net Core而不是重用Mono的有趣的事情？
PowerShell已经是一个一年半的开源项目，但是我看到在这个存储库中，只有一个社区的人对@markekraus代码做出了系统的贡献，只有一个人对@ mklement0进行了系统的分析。
我认为，如果我们将项目分成几个部分，那么我们将获得更多的贡献。
我认为明天情况不会改变。 我不会指望它。

我非常希望@markekraus在http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov提出了有关第三方模块的支持，信任和维护的要点。 某些第三方模块可以像Pester这样成功而成熟。
但是，不应以为伟大的YAML模块将在未来几年内自行发展。 实际情况是，大多数模块都是由解决特定问题并发布其通用基本代码的好行为的作者发布的。 这就是我们最终获得两个旨在解决同一问题的模块的方式。 理想情况下，将需要合并它们以集中精力，否则它们将在未来进一步分散或变得陈旧，很快其他人将发布更多模块。
拥有适当的解析器的潜在问题表明，拥有一个良好的YAML模块是必需的（需要大量的努力）基础工作。
我不是YAML专家，但这仅仅是语言规范本身的问题，还是诸如VSTS或AppVeyor之类的各种系统对特定解释的问题，还是仅缺少一个良好的解析器？
我发现在VSCode中编写YAML以及仅在VSTS中运行它以得到VSTS解析器不喜欢它的错误时感到沮丧...

对我来说，这种对话就是开源“代码管理/体系结构”问题的一个典型例子。

开源提供了良好的基础思想和代码基础-但是，如果在采用它作为最通用的解决方案时没有给予认真的体系结构关注-则它是10年的错误修复程序，这些错误修复程序可以在体面的设计评审中予以解决。 。

在@bergmeister的“成熟成功”的真实案例中，通常是一个积极的维护者，承担了通用代码库的任务。 但这不能保证会发生。

我认为我们当中有些人在说“ YAML支持就像对写入文件的支持-它是核心-应该以相同的方式构建=>以成为该功能的黄金标准”

1）开源的半体系结构属性与2）YAML的核心性质的结合，似乎使我们许多人都强烈要求采用高度架构化的方法，我们知道Microsoft PowerShell开发人员将其应用于他们的工作。 不一定会摆脱开源可以帮助我们的所有其他有趣事物。

关于软件成熟度的非常有效的观点。 我没有仔细查看此处列出的两个模块，也没有仔细查看yamldotnet的意见。 在开始计划6.2.0时可以看到的东西

不要误会我的意思，我确实重视PowerShell团队和MSFT开发人员的经验和系统的方法，我只是认为他们试图用自己加盖MSFT的模块来填补所有空白是错误的...无法扩展（我们已经看到了DSC资源的问题）。
越来越依赖MSFT提供的模块是脆弱的，并且无助于社区的发展，也无助于生态系统的多样性。
我赞成MSFT为开源项目做出贡献，以分享他们的经验并帮助改进实践和质量，同时又不对它们产生依赖性（因为您知道，松鼠...！）。
_MSFT是获批准的事物的唯一提供者_是他们已经努力学习的旧模型，并且它无助于社区鼓励这种方法（即_我将等待或抱怨微软未解决我遇到的问题_ OSS生态系统中的一种态度）。

我同意YAML的支持是核心，而不是PS团队从头开始重写，为什么不帮助项目的现有维护人员进行改进，并给他们提供合并项目并听取他们意见的机会。 有点像PS团队在核心功能模块上的学徒/指导。
只是重新编写一个新模块听起来像工程师对解决不是工程问题的反应。 对于PS团队来说，重新编写YAML模块是一项轻松的工程任务，但是不会（帮助）解决社区成熟度问题，也不会给出正确的激励措施。
尽管Yaml是否是解决此问题的战略项目，但这是MSFT的要求：)

@伯格梅斯特

我将以自己不是YAML专家的身份作为开头。 当我想将像yaml configs这样的AppVeyor烘焙到我自己的科学怪人管道中时，我碰巧对此做了一些研究。 我研究了十几个C＃项目正在使用YAML。 由于PowerShell项目使用YamlDotNet，因此我只能假设这并不容易。 尽管我至少对PSYaml和powershell-yaml有所了解，但对使用它们的一些PowerShell项目的关注却较少。

我不是YAML专家，但这仅仅是语言规范本身的问题，还是诸如VSTS或AppVeyor之类的各种系统对特定解释的问题，还是仅缺少一个良好的解析器？

我怀疑YAML的本质是人类可以读取，但可能会被机器更容易地读取。 这种可读性优先的范式扩展到YAML作者编写YAML文件的方式。 尽管生成的YAML符合YAML规范，但在不使用反序列化对象作为实际有用对象的中介的情况下，将其解析为无法在代码中使用。

也就是说，从YAML反序列化到对象的90％的时间不是问题，而是数据设计/体系结构。 其他10％的时间是我只能总结为“ YAML很难解析，伙计”。 但是，反序列化的对象通常仅比对您要查找的内容重新使用有用。

例如，AppVeyor.yml中的安全字符串

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

powershell-yaml和YamlDotNet确实将其转换为对象，但是使用它时没有多大逻辑，也很幸运。 一旦有了这种逻辑，就对这种架构有好处，但是另一个呢？

其中一些同样的数据设计问题困扰着JSON，但根据我的经验和观点，由于JSON的更严格的性质，使模型可以解决这些缺点变得容易得多。 如果可能的话，试图为该线程中提到的任何YAML反序列化器创建模型都是一场噩梦。

当然，模型不是JSON cmdlet当前可用的功能，尽管我真的很想添加它。 如果我在“官方” YAML模块/ cmdlet中有发言权，那么我会将其说成“必须具备”功能。 这是一个错失的机会，尤其是在v5中添加了PowerShell类。

IMO，仅将YAML字符串放入对象中是不够的。 这似乎很容易（至少90％的时间）。 诀窍是将YAML字符串放入_useful_对象。 这就要求解决方案具有一定的灵活性。 但是这种灵活性也必须在某种程度上可以实现，并且不需要@IISResetMe和@lzybkr来为您提供序列化建议...。

为此，我没有看到任何适用于一般范围的东西。 项目采用可用的解决方案，然后将其输出用作实际有用对象的中介（导致可能需要在上游进行大量重新发明）。 或者，这些项目损害了YAML的可读性，以便于从YAML解析为对象。

@gaelcolas

我同意YAML支持是核心，而不是PS团队从头开始重写，为什么不帮助项目的现有维护者进行改进，并为他们提供合并项目并听取他们的意见的机会

问问自己为什么MSFT开始.Net Core项目而不是多年后继续进行Mono。

MSFT也是一个社区。 与任何社区一样，与其他社区的互动也存在相同的问题。

就上下文而言，我并不是说要从头开始做任何工作-可以采用代码-但应在改进之前从系统开发体系结构的角度对其进行审查。 经过审查并重新发布

我的观点是，对一个团队进行重要的体系结构审查和修复，以彻底了解几乎所有地方都将利用的核心代码的细微差别。

始终值得考虑的另一个模型是获取/合同/秒。 在此基础上，我们努力与一个或多个社区成员/公司达成商业条款，以招募他们的服务，以MSFT主导/促进的开发周期来重新升级和（以某种方式）集成/连接产品。 。 Xamarin成功地做到了这一点，后者将项目踢给了Net Foundation，并在MIT的许可下进行了开发，并通过Xamarin招募/签约/涉及了关键资源，例如Miguel de Icaza和Nat Friedman。 有人抱怨这是开源叛国罪。 但是，这确实为人们和小公司构思和开发项目提供了积极的动力，这些项目以后可能适合广泛采用并整合到至少一个主要的生态系统中。 当然，最好直接跳到内部重做，复制整个概念和功能以及许多想法，但抛弃创建者和（表面上）代码。

@iSazonov很抱歉回复晚，没有platyPS yaml解析器不好：它仅支持键值对。 我们还使用YamlDotNet在此处生成yaml。

关于将其排除在核心功能集之外的观点：与Ruby，Python或Node.js相比，PowerShell处理依赖项的方式有很大的不同。

这些语言中的每一种都有依赖项管理工具（bundler，pip，npm / yarn），这些工具使外部依赖项的管理变得容易，更重要的是可重现。 像Gemfile/Gemfile.lock或package.json/package-lock.json [,yarn.lock]这样的东西可以很容易地安装所有必需的软件包，并确保您停留在非常特定的补丁程序级别上，这是非常重要的区别，在我看来，是什么使得第三方库在某些基本方面可行。

也许可以使用Nuget来解决此问题，但是我从未见过任何文章描述PowerShell的依赖性管理策略/模式。 拥有图库非常棒，但是如果您必须手动安装所有必需的软件包，则对于任何重要的部署来说都是不可行的。

编辑：
因此，似乎我正在寻找的_may_已经可用： https ://docs.microsoft.com/zh-cn/powershell/wmf/5.0/psget_moduledependency

@bgshacklett提出了一个非常好的观点。

@ chuanjiao10-请停止对该存储库中的许多问题进行破坏性评论，正确的解决方案不是将它们包含在Microsoft.PowerShell.Utility模块中，实际上将它们作为单独的模块运送到PowerShellGallery中托管

当您用母语说的时候，您是指XML还是JSON？

当前的想法是，YAML根本不应该包含在PowerShell中，而应该是一个单独的模块，您可以在不使用新版PowerShell的情况下对其进行更新。

如果将YAML像XML一样嵌入到PowerShell中，那将是不可能的（请考虑[xml]“ b”）

如果我们采用JSON路线，则将有cmdlet与YAML一起使用-因此并没有真正融入PowerShell中，但是仍然存在需要更新PowerShell来获取YAML更新的缺点。

就个人而言，这似乎是收件箱中“正确”的事情，我建议这实际上不是正确的事情

@lzybkr我知道我们说过我们不想引入一个新的图书馆，但是我认为这是我们可能需要重新评估的事情。 理想情况下，我们也应该将该模块运送到Gallery上，但是我认为现在有很多现代方案都需要YAML。

也许不在6.0时间范围内，但是我们应该谈论它。

在我看来，交付一个外部模块要好得多，因为可以在较低级别上使用它，而且与IMO相比，PowerShell的团队工作少了，而在PowerShell团队的帮助下，更多的社区推动了这一工作，从而尽可能地提高了质量。

再次@ chuanjiao10 ，以前曾决定不将YAML Cmdlet放入＃2109中的PowerShell Core中，然后被正确拒绝，因为现在也应该将其关闭。

关于

团结就是力量。 一个需要汽车的美国人，您看到他去沃尔玛买轮毂，去亚马逊买引擎，并结合自己（自己动车）吗？

将汽车与软件进行比较有点不好，因为汽车中的组件来自许多不同的供应商，然后被打包成可用的产品，这与社区开发的PowerShell模块没什么两样，可以将其进行混合和匹配，在脚本中使用

关于这一点

主库是内置的，这非常重要，否则我看到convertfrom-json，convertto-json等也应该放在PowerShellGallery中。

我一直提倡在＃1979中使用尽可能多的内置模块，并希望PowerShell Core尽可能精简，在＃5681中已开始对此进行进一步的讨论。

并重新

不要歧视YAML，不要奉承JSON。

我既不区分Yaml也不要奉承Json，因为它们都有缺点，但是都具有它们的用途，如果我能够影响不要在PowerShell中交付Json cmdlet，我将做与在此所做的完全相同的事情。

我认为重新讨论一下可能会有所帮助。 特别是，那些支持将YAML包含在核心语言中的人是否愿意列出特定的用例？为什么PowerShell画廊中的模块不足以解决所述用例？ 到那时，我们可以进行以需求为导向的讨论，并有可能找到解决当前问题的可行解决方案。

我的主要用例是用于操作系统和应用程序部署的裸机自动化。 在至少一种情况下，我想读取一个YAML文件，该文件调用了我的脚本以了解参数。
在这些情况下，服务常常依赖于我们的外部非SLA服务，这是一个很大的禁忌。 它可能会影响生产扩展活动。

这是我在Powershell核心的最基本封装中发货的用例。

我感谢热烈的讨论，让我们尽量保持礼貌:)

@ PowerShell / powershell-committee先前已对此进行了讨论。 我们同意支持YAML至关重要，因为它在当今如此普遍。 我们还希望看到我们目前已移出PSCore6的更多模块，以便您从最小安装PSCore6开始，然后添加所需的内容（使用元模块，您不需要添加10个以上的模块，只需一个DevOps ）。 因此，对于YAML，当前的想法是这应该是一个单独的模块（如果有人准备开始对此进行原型设计，那么我可以在PowerShell org下创建一个存储库，我的团队目前没有带宽）。 一旦从技术，许可，支持的角度对YamlDotNet（或其他第三方库）进行了评估（类似于我们对Json.Net的依赖），就可以使用YamlDotNet（或其他第三方库）。 但是，上次我们查看YAML和YamlDotNet时，问题在于YAML的实现差异很大，并且该库不支持其中的所有功能（甚至不支持某些流行的功能）。

我只是说YAML支持是我希望团队关注6.2版之后的版本。

@ SteveL-MSFT您能否根据问题和https://github.com/dotnet/corefx/issues/34578发表评论

in。我的意见是让convertfrom-json，convertfrom-jaml具有相同的状态，无论是移出还是内置。

我一直提倡将JSON cmdlet移出项目。 许多人想进行很多更改，这将是相当大的更改，但是由于cmdlet与PowerShell绑定，因此无法进行更改。 将它们移出项目可以使我们在cmdlet模块的新主要版本中进行重大更改，并且PowerShell附带了较旧版本，该版本提供向后兼容性，但允许用户根据需要进行更新...。包括这样的外部模块，IMO十分麻烦。

我宁愿我们从JSON和Pester的错误中吸取教训，而不是以相同的方式任意对待YAML。 它绝对不应该是PowerShell核心功能的一部分，而应该绝对具有某种官方支持的模块，该模块在社区和PS团队之间拥有共享所有权。

我喜欢这个主意。 将JSON Cmdlet移出将有助于解决当前存在的工作流程问题，这些问题存在对外部模块的严格依赖性。

但是yaml对于系统管理员，脚本开发人员很重要。这些用户需要yaml命令。

他们可能需要它们，但这并不意味着它们需要直接包含在PowerShell中，因为外部模块比捆绑到核心存储库中的任何东西都更令人接受，并且具有更灵活的支持生命周期。

我不得不说，从长远来看，@ SteveL-MSFT的DevOps元模块的想法确实是正确的方法，因为这允许不同的用户集获得更简单的软件包集，这些软件包更易于管理作为一种外部依赖关系，而不是内部依赖关系，对我来说很有意义，尽管它们应该是基于技术堆栈的元模块，因为如果我在Windows上而不使用anisble，那为什么我需要yaml cmdlet视窗？

正如@ chuanjiao10所述，尽管在Linux世界中有大量用户使用yml，但在Windows世界中却并非如此，从我对PowerShell整体使用的理解来看，PowerShell 5.1仍然在很大程度上依附于他们的系统中，并且虽然捆绑Yaml cmdlet可能对Linux用户有帮助，但在我看来，这对Windows用户来说是不必要的额外捆绑项目，但对两组用户都一视同仁，这使得它最终成为两组用户的外部模块是最有意义的可以根据需要利用

是否有人想成为所有者并在单独的项目中陪同这些cmdlet？

@iSazonov似乎corefx当前对内置的YAML支持不感兴趣。 YamlDotNet似乎是最受欢迎的库，它是MIT许可的，并得到了积极维护，因此我将从这里开始。 社区驱动的项目将是惊人的，而且比您将其留给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需要在包装箱中捆绑PowerShell Core的YAML支持。 干净利落。

@brettjacobson是的，这将是简单，简单和高质量的，但是MSFT团队没有那么多资源。 您准备好捐款了吗？ :-)

@brettjacobson -Microsoft不需要捆绑YAML支持。 如果他们这样做，可能会有用，但他们没有这样做的要求，也根本没有必要这样做。

这是对许多want的功能请求，最终将是use但不是关键的need ，因此_unlikely_要获得优先级，这正是@ SteveL-MSFT当他说以下时，他试图去

我只是说YAML支持是我希望团队关注6.2版之后的版本。

社区驱动的项目将是惊人的，而且比您将其留给PowerShell团队执行的时间更早。

PowerShell团队并不庞大，因此，从现实的角度来看，能够获得YAML支持的最佳，最快方法将是PowerShell核心功能集的外部，而不是融入产品本身。

CoreFX团队询问用例。 如果PowerShell项目说我们需要API，他们将考虑添加API。

@iSazonov恕我直言，

那么，您是要等待“大型”第三方库还是让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问题＃5681建议使用带有一组通用模块（例如Pester等）的PowerShell的“丰富”版本。请在本期中发布，但鉴于似乎没有在当前2个可用的yaml模块之间显然是赢家，并且它们之间相互影响，要选择一个收藏夹可能是一个艰难的决定。

我只看到一个YAML :(

Pester ，是的。 太重了，无法将BDD框架发布到主线中，这与我的pwsh容器应用程序的YAML阅读器不同。

该线程是否已结束。 Microsoft使用的推荐（或推荐）模块是什么？
DevOps管道使用yaml。 我所有的部署自动化都是使用powershell构建的。 似乎yaml和powershell不能很好地发挥作用。 Powershell是Azure DevOps自动化的错误选择吗？
需要仔细考虑我将来的使用/创新，并希望能有所指路。
提前致谢！

@dirkslab您可以使用https://github.com/cloudbase/powershell-yaml

的GitHub

cloudbase / powershell-yaml

用于YAML格式操作的PowerShell CmdLets。 通过在GitHub上创建一个帐户来为cloudbase / powershell-yaml开发做出贡献。

感谢@iSazonov ，这是我目前正在测试的解决方案。 到目前为止，该解决方案似乎工作正常。 使用该解决方案可能没有错。

请注意，使用powershell-yaml需要确定一个不受信任的模块。 这是我要努力理解的部分。 Microsoft建议使用yaml管道。 微软（或至少是该线程）建议使用3rd party模块，以便您可以将yaml config与powershell集成在一起，但不要认可或推荐任何模块。 您如何从逻辑上向企业解释。
到目前为止，我的经验一直是，如果您不使用Microsoft认可的解决方案，那么对于解决方案问题（如果不受支持的部分碰到任何会引起问题的问题，这都无所谓）将失去Microsoft的任何支持或理解。 仅有不支持的部分这一事实通常导致没有支持/责任。
也许在这个开放源码时代已经发生了变化。 微软提供的简单官方回应和指导会让我放心并帮助我理解。

感谢您的回应。 问候。

@dirkslab我认为您的MSFT客户经理是询问支持政策的合适人选。

CoreFX团队询问用例

Appart受益于yaml如今已在CI / CD中广泛存在的优势以及配置系统的数量，ConvertTo-Yaml的附加优势在于以人类可读的格式表示nasted HashTable ，与我们现在必须使用的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)

拥有具有强大功能的飞船将在向CI团体传福音方面带来变革。
“如果我们切换到ms powershell，我们可以自动进行”->“告诉我更多吗？”
与
“如果我们切换到ms powershell并从图库中下载一些脚本，则->“否”

1. 确实，这是逐个方式，但是yaml是json的超集，因此json是yaml的缩写形式，高效的yaml解析器是高效的json解析器，

可以重新考虑7.1吗？ 我在使用不受信任的模块和某些问题时也遇到了问题，因此DevsOpsy应该确实是PowerShell固有的。

恕我直言，YAML与JSON和CSV一样流行，并且在PowerShell中没有用于YAML的收件箱转换器有点令人遗憾。 拥有收件箱YAML转换器还可以确保其行为与JSON转换器相同，而社区模块则不是这样。

不要误会我的意思-非常感谢人们为社区创建模块，但是在目前的世界状况下，YAML转换是赌注-我们不希望人们下载用于JSON转换的第三方模块。