Powershell: ConvertFrom-Yaml, ConvertTo-Yaml

Tivemos uma discussão semelhante do aspecto DSC ,
permitindo-nos alterar os arquivos de configuração baseados em json, queríamos ter opções para modificar arquivos baseados em xml, arquivos baseados em YAML, arquivos baseados em INI com suporte a trocas RegEx de dentro de cmdlets de Manipulação de Texto.

A falta de suporte existente no PS significa que temos que trabalhar muito para obter essa capacidade.
Ele está em espera, aguardando a contribuição da comunidade, mas se fosse incorporado ao PS, seria muito mais fácil para a parte do DSC também.

Quando você diz nativamente, você quer dizer como XML ou JSON?

O pensamento atual é que YAML não deve ser incorporado ao PowerShell, em vez disso, deve ser um módulo separado que você pode atualizar sem pegar uma nova versão do PowerShell.

Se YAML fosse incorporado ao PowerShell como XML, isso seria impossível (pense em [xml] " b ")

Se seguirmos a rota JSON, você terá cmdlets para trabalhar com YAML - então não realmente embutido no PowerShell, mas ainda terá as desvantagens de precisar atualizar o PowerShell para obter atualizações YAML.

@lzybkr Sei que dissemos que não queríamos trazer uma nova biblioteca, mas acho que isso é algo que precisamos reavaliar. Idealmente, deveríamos também enviar o módulo na Galeria, mas acho que uma tonelada de cenários modernos exigem YAML agora.

Talvez não no prazo 6.0, mas devemos conversar sobre isso.

@ArieHein - Tenho algumas funções simples que salvam e recuperam uma matriz hash no registro. Manuseie apenas REG_SZ - mas para um conjunto simples de configurações é suficiente - diga-me se deseja uma cópia.

Eu falei errado quando disse "nativo" - principalmente quis dizer "embutido" - não me incomodaria se eles fossem módulos de script que pudessem ser atualizados.

Nossa primeira discussão # 2109

@iSazonov - ah sim, entendo!

Notei a referência ao suporte da AWS para YAML no thread - tenho convertido alguns modelos e achei isso útil: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov obrigado pelo ponteiro, não consegui encontrar por algum motivo. Lembre-se bem disso.

Ao reler o thread original, acho que devemos definitivamente implementar os cmdlets em algum momento no futuro e enviá-los na Galeria. Com base em sua qualidade e na utilidade percebida das pessoas (junto com algum trabalho de refatoração que esperamos fazer após 6.0.0), podemos fazer a chamada in-box vs. apenas Gallery.

Temos Yaml em https://github.com/PowerShell/platyPS

sim, seria incrível ter, acabou usando https://github.com/awslabs/aws-cfn-template-flip para converter

@MattTunny Bem-vindo a contribuir! :-)

Há uma voz de usuário do Windows Server aberta para votar nele :-)

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

Isso definitivamente deve fazer parte da biblioteca nativa do PS 6.1. Muitas coisas hoje em dia estão no YAML.

Existem agora psyaml e powershell-yaml módulos no PSGallery, mas ambos não são capazes de fazer o round-trip de um arquivo YAML de uma definição de compilação VSTS. Não me importo se o módulo é incorporado ao PowerShell ou é um módulo do PSGallery.

Eu me pergunto se o principal problema aqui é a maneira desajeitada como implantamos os módulos. Hoje, você precisa encontrar, confiar e instalar um módulo antes de poder usá-lo. Compare isso com a maneira (aparentemente) engenhosa que o Javascript faz var m = require('mymodule') . Talvez devêssemos ter alguma maneira de fazer o que o DSC faz, exceto pelo PowerShell nativo. No DSC, quando um módulo é referenciado em uma configuração, ele é baixado e instalado automaticamente no nó de destino sem esforço manual. Disponibilizar módulos críticos, mas não essenciais, dessa forma deve eliminar os argumentos "deve ser parte do núcleo". E para nós que estão desconectados da rede, poderíamos ter uma ferramenta que agrupasse as dependências em um script em um arquivo que é então implantado no destino. É assim que a extensão de recurso DSC do Azure funciona - há uma ferramenta que verifica um script para descobrir os módulos necessários e, em seguida, cria um arquivo zip contendo tudo o que é necessário e o publica em um blob. A extensão de recurso do Azure, em seguida, extrai esse blob, instala os módulos e executa o script.

Para algo que é tão importante, eu realmente não quero depender de uma biblioteca de terceiros, a menos que eu tenha alguma forma de vendê-la. É muito fácil para os desenvolvedores terceirizados quebrar ecossistemas inteiros (consulte https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

Deixando de lado as questões mais amplas, atualmente não há um bom módulo YAML para PowerShell, como @bergmeister apontou. Esta é uma obrigação para uma linguagem fortemente voltada para a automação. Os arquivos de configuração baseados em YAML são extremamente populares agora e é muito difícil evitá-los, mesmo se você não tiver que se contentar com as opiniões de uma equipe para fazê-lo. Pense no raciocínio por trás da inclusão de XML e JSON como partes centrais da linguagem. O caso de YAML realmente não é tão diferente.

@bgshacklett Pelo que ouvi dos caras do Puppet, simplesmente não há bons analisadores YAML :-)

O analisador platyPS é bom o suficiente?

@vors Existe uma maneira simples de reutilizar o analisador PlatyPS YAML no repositório PowerShell Core?

Prefiro a ideia de um módulo oficial separado na Galeria do PowerShell, como @lzybkr diz, porque seria possível usá-lo em versões mais antigas do PowerShell e poderia ter seus próprios lançamentos. Isso seria como o módulo sqlserver . @BrucePay se fosse uma página da Galeria do PowerShell com módulos próprios da Microsoft, seria mais fácil de encontrar e todos saberiam que podem confiar neles.

Mas eu entenderia se fosse feito backup no Powershell como XML e JSON.

O importante é que existem funções oficiais ConvertFrom-YAML e ConvertFrom-YAML porque YAML é um formato amplamente utilizado para arquivos de configuração e não deve ser um módulo de terceiros, como @bgshacklett aponta.

Fiz uma entrada de blog testando e comparando os dois módulos que descobri para funcionar com arquivos YAML: PSYaml e powershell-yaml .

Eles têm comportamentos diferentes porque internamente estão usando objetos diferentes:

| módulo | mapeamentos | sequências |
| --------- |: -------------- | ----------- |
| PSYaml | OrderedDictionary | Array |
| powershell-yaml | Hastable | Lista

Acho que precisamos de um ConvertFrom-YAML padrão e ConvertFrom-YAML .

Na verdade, ConvertFrom-Yaml em powershell-yaml usa OrderedDictionary ao converter com o parâmetro -ordered .
Eu tenho usado este módulo com sucesso por um tempo (no meu módulo Datum para dados de configuração DSC e com yamls de cozinha), mas não tenho uma definição de compilação vsts para testar.

Lembre-se de que a maneira certa de chamá-lo é: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (as pessoas geralmente sentem falta de -Raw ).

Eu me pergunto por que precisaríamos de um módulo _oficial_ da Microsoft, colocando ainda mais sobrecarga no MSFT e reinventando a roda ... Talvez tentando contribuir com um existente primeiro, adicionar testes para evitar regressão, abrir problemas para ter certeza de que o proprietário conhece o problemas é uma abordagem melhor ...
Você sabe o que acontece quando você tenta criar um padrão entre as 99 implementações existentes ...

E sim seria melhor fora do idioma, concordo que o gerenciamento de dependências poderia ser melhor, agrupar tudo em PS não é uma solução.
O amplo problema do npm também é uma falha no processo. Bifurcar e republicar consertou isso em nenhum momento, construir aplicativos a partir da versão mais recente da Internet foi o motivo pelo qual quebrou tantos aplicativos ativos.

Eu concordo com @gaelcolas. Acho que isso é melhor com todos trabalhando com os proprietários de um módulo de comunidade existente para aumentar e garantir a qualidade.

Vou apenas acrescentar que os testes para tal projeto devem incluir trabalhar com um grande número de arquivos YAML do mundo real para coisas como AppVeyor, Travis CI, VSTS, AWS CloudFormation, etc. Para minha própria experiência com desserilização YAML, tive pouco sucesso com uma solução funcionando universalmente e, no final das contas, tive que reinventar a roda várias vezes. Nesse sentido, concordo com @BrucePay "simplesmente não existem bons analisadores YAML".

Estamos falando sobre este módulo platyPS porque ele já é usado ativamente no ambiente de Ajuda do PowerShell. Acho que ninguém da MSFT pode dizer como este módulo é bom por causa do Código de Conduta. Eles podem rejeitá-lo silenciosamente ou melhorá-lo.
E embora já falemos sobre isso há muito tempo, não vejo como poderíamos usar os componentes deste módulo aqui de uma forma simples.
Talvez @adityapatwardhan e @ SteveL-MSFT abram seus planos e cronograma, especialmente porque o novo Help RFC já está em estágio de experimento.

Minha opinião pessoal é que eu preferiria ver mais módulos de comunidade bem-sucedidos e se tornarem padrão de fato do que exigir módulos "oficiais" do Msft.

@iSazonov Uma coisa é ter uma solução que funcione para serializar / desserializar um esquema bem definido. Outra bem diferente é ter uma solução que funcione em geral com todos os esquemas compatíveis com YAML.

Eu entendo o desejo da MSFT de reutilizar projetos comunitários para cortar custos. Mas a situação é, de fato, que a MSFT pode não fazer uso de tantos projetos comunitários:

• muitos têm código ruim, não têm confiança
• muitos projetos são uma pessoa

A MSFT publicou as especificações do Powershell há mais de 10 anos, mas ninguém as portou ainda até a MSFT.
O projeto OpenSSL existe há muitos anos, mas ninguém o portou para o Windows enquanto a MSFT não fez isso.
A MSFT revelou muitos milhares de interfaces de API, mas quantas delas foram portadas para Unix?
O interessante sobre por que a empresa lançou seu projeto .Net Core em vez de reutilizar Mono?
PowerShell já é um ano e meio é um projeto de código aberto, mas vejo que neste repositório apenas uma pessoa da comunidade faz contribuição sistemática no código @markekraus e apenas uma pessoa faz análise sistemática @ mklement0.
Não acho que se dividirmos o projeto em partes, teremos mais contribuições.
Não acho que a situação vai mudar amanhã. Eu não contaria com isso.

@markekraus , espero muito em http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov traz pontos importantes sobre suporte, confiança e manutenção de módulos de terceiros. Alguns módulos de terceiros podem se tornar um sucesso e amadurecer como, por exemplo, Pester.
No entanto, não se deve presumir que um grande módulo YAML irá evoluir por conta própria nos próximos anos. A realidade é que a maioria dos módulos é publicada por autores que resolveram um problema específico e fizeram a boa ação de publicar seu código base genérico. Assim acabamos com 2 módulos que visam resolver o mesmo problema. Idealmente, seria necessário mesclá-los para concentrar os esforços, caso contrário, eles se afastarão ainda mais no futuro ou apenas ficarão obsoletos e logo haverá mais módulos publicados por outras pessoas.
O problema subjacente de ter um analisador adequado indica que um trabalho de base básico (e substancial em termos de esforço) é necessário e requerido para ter um bom módulo YAML.
Eu não sou um especialista em YAML, mas isso é apenas um problema da própria especificação de linguagem ou interpretação específica por vários sistemas como VSTS ou AppVeyor ou isso é apenas a falta de um bom analisador?
Achei frustrante escrever YAML no VSCode e apenas ao executá-lo no VSTS para obter um erro que o analisador VSTS não gostou ...

Para mim, esta conversa é um caso em questão com o problema de "curadoria / arquitetura de código" do código-fonte aberto.

O código aberto oferece boas ideias de propagação e bases de código - mas se um olhar sério de arquitetura não for dado a ele quando adotado como a solução mais geral - então são 10 anos de correções de bugs para itens que poderiam ter sido resolvidos em uma revisão de design decente .

Nos verdadeiros casos de @bergmeister "sucessos maduros", geralmente é um mantenedor ativo que assumiu a missão de generalizar a base do código. Mas isso não pode acontecer.

Acho que alguns de nós estão dizendo "O suporte YAML é como o suporte para escrever arquivos - é o núcleo - deve ser arquitetado da mesma forma => com a intenção de ser o padrão ouro para essa funcionalidade"

A combinação de 1) o atributo semi-arquitetado do código aberto com a 2) natureza central do YAML que parece fazer muitos de nós desejarmos a abordagem altamente arquitetada que sabemos que os Desenvolvedores do Microsoft PowerShell aplicam ao seu trabalho. Não é necessariamente um desvio de todas as outras coisas legais que o código aberto pode realmente nos ajudar.

Pontos muito válidos na maturidade do software. Não olhei de perto os dois módulos listados aqui, nem o yamldotnet para fazer qualquer opinião. Algo que podemos observar ao começarmos o planejamento para 6.2.0

Não me interpretem mal, eu valorizo ​​a experiência e abordagem sistemática da equipe do PowerShell e desenvolvedores MSFT, só acho que é errado para eles tentarem preencher todas as lacunas com um módulo de seu próprio MSFT carimbado ... não escalar (e já vimos o problema com os recursos de DSC).
Aumentar a dependência dos módulos fornecidos pela MSFT é frágil e não ajuda a aumentar a comunidade, nem a diversidade do ecossistema.
Sou a favor da contribuição da MSFT para projetos de código aberto para compartilhar sua experiência e ajudar a melhorar as práticas e a qualidade, sem criar uma dependência deles (porque você sabe, esquilos ...!).
A _MSFT como fornecedora exclusiva de coisas aprovadas_ é um modelo antigo sobre o qual eles já lutam para educar, e não está ajudando a comunidade a encorajar essa abordagem (ou seja, _Eu vou esperar ou reclamar da Microsoft por não resolver o meu problema_ tipo de atitude no ecossistema OSS).

Concordo que o suporte YAML é fundamental, em vez da equipe PS reescrever do zero, por que não ajudar os mantenedores existentes de projetos a melhorar e dar a eles a oportunidade de fundir projetos e ouvir deles o que seria necessário. Um pouco como um aprendizado / orientação da equipe PS em módulos de funcionalidade central.
Apenas reescrever um novo módulo soa como a reação de um engenheiro para resolver um problema que não é um problema de engenharia. Reescrever um módulo YAML é uma tarefa _fácil_ de engenharia para a equipe PS, mas não (ajudaria) consertar o problema de maturidade da comunidade, nem daria o incentivo certo.
Se Yaml é o item estratégico para lidar com isso é decisão da MSFT :)

@bergmeister

Vou prefaciar isso comigo mesmo, não sendo um especialista em YAML. Acontece que eu fiz algumas pesquisas sobre isso quando eu queria assar alguns configs AppVeyor like yaml em meu próprio franken-pipeline. Observei como cerca de uma dúzia de projetos C # estavam consumindo YAML. Como os projetos do PowerShell usam YamlDotNet, só posso supor que não seja mais fácil. Embora eu pelo menos tenha brincado com PSYaml e powershell-yaml e tenha olhado menos de perto para alguns projetos do PowerShell que os usam.

Eu não sou um especialista em YAML, mas isso é apenas um problema da própria especificação de linguagem ou interpretação específica por vários sistemas como VSTS ou AppVeyor ou isso é apenas a falta de um bom analisador?

Eu suspeito que seja da natureza do YAML ser legível por humanos às custas de ser mais facilmente legível por máquinas. Esse paradigma de legibilidade em primeiro lugar se estende à maneira como os autores YAML escrevem seus arquivos YAML. Embora o YAML resultante seja compatível com as especificações YAML, ele é analisado de forma a ficar inutilizável no código sem usar o objeto desserializado como intermediário para um objeto realmente útil.

Ou seja, 90% das vezes, a desserialização de YAML para um objeto não é o problema, mas o design / arquitetura de dados é. Nos outros 10% do tempo _é_ problemas de análise para os quais eu só posso riscar como "YAML é difícil de analisar, cara." No entanto, os objetos desserializados geralmente são apenas um pouco mais úteis do que regexar o que você está procurando ....

Por exemplo, as strings seguras em AppVeyor.yml

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

powershell-yaml e YamlDotNet convertem isso em um objeto, mas boa sorte usando-o sem um monte de lógica. Depois de ter essa lógica, bom para esse esquema, mas e outro?

Alguns desses mesmos problemas de design de dados afetam o JSON, mas é (na minha experiência e opinião) muito mais fácil fazer modelos que podem contornar essas deficiências devido à natureza mais rígida do JSON. Tentar fazer modelos para qualquer um dos desserializadores YAML mencionados neste tópico é um pesadelo se e onde for possível.

Concedido, os modelos não são um recurso disponível atualmente nos cmdlets JSON, embora eu realmente gostaria de adicioná-lo. Se eu pudesse opinar sobre o módulo / cmdlets YAML "oficiais", eu o colocaria como um recurso "obrigatório". É uma oportunidade perdida, especialmente com a adição de classes do PowerShell na v5.

IMO, apenas colocar strings YAML em um objeto não é bom o suficiente. Isso parece ser fácil (90% das vezes, pelo menos). O truque é colocar strings YAML em objetos _useful_. Isso requer alguma flexibilidade da solução. Mas essa flexibilidade também deve ser acessível e não exigir que @IISResetMe e @lzybkr forneçam conselhos sobre serialização ....

Para esse efeito, não vi nada que funcione de forma geral. Os projetos adotam as soluções disponíveis e, em seguida, usam sua saída como intermediários para objetos realmente úteis (levando a uma série de reinventações de rodas que provavelmente deveriam ser feitas no upstream). Ou, os projetos comprometem a legibilidade YAML para facilitar a análise de YAML para objetos.

@gaelcolas

Concordo que o suporte YAML é fundamental, em vez de a equipe PS reescrever do zero, por que não ajudar os mantenedores existentes de projetos a melhorar e dar a eles a oportunidade de fundir projetos e ouvir deles o que seria necessário

Pergunte-se por que a MSFT iniciou o projeto .Net Core em vez de continuar Mono muitos anos depois.

A MSFT também é uma comunidade. E como qualquer comunidade tem os mesmos problemas de interação com outras comunidades.

Para o contexto, não estou sugerindo que nenhum trabalho seja feito do zero - o código pode ser adotado - mas deve ser examinado a partir de uma perspectiva de arquitetura de Desenvolvimento de Sistemas antes de ser melhorado. Pode até ser de código aberto após essa revisão e relançamento.

Meu objetivo é ter uma revisão arquitetônica significativa e remediação de uma equipe que entende completamente as nuances do código principal que serão aproveitadas virtualmente em todos os lugares.

Outro modelo que sempre vale a pena considerar é adquirir / contratar / segundo. Com base nisso, um esforço é feito para chegar a termos comerciais com um ou mais membros da comunidade / empresas para recrutar seus serviços para um ciclo de desenvolvimento liderado / facilitado por MSFT para reconstituir e (de alguma forma) integrar / conectar o (s) produto (s) . Isso foi feito com sucesso com o Xamarin, que lançou o projeto para a Net Foundation, licenciou-o sob o MIT e recrutou / contratou / envolveu recursos-chave, como Miguel de Icaza e Nat Friedman via Xamarin. Alguns reclamam que isso é traição de código aberto. Mas cria incentivos positivos para que pessoas e pequenas empresas concebam e desenvolvam projetos que mais tarde poderiam ser adequados para ampla adoção e integração em pelo menos um grande ecossistema. Certamente é preferível pular direto para uma tela em branco refazer internamente que copia todo o conceito e funcionalidade e muitas das idéias, mas descarta os criadores e (aparentemente) o código.

@iSazonov desculpe pela resposta tardia, não, o analisador platyPS yaml não é bom: ele suporta apenas pares de valores-chave. Também usamos YamlDotNet para gerar yaml lá.

Em relação ao sentimento de manter isso fora do conjunto de recursos principais: há uma diferença muito significativa em como o PowerShell lida com dependências em comparação com, digamos, Ruby, Python ou Node.js.

Cada uma dessas linguagens possui ferramentas de gerenciamento de dependências (bundler, pip, npm / yarn) que tornam o gerenciamento de dependências externas fácil e, mais importante, reproduzível. Ter algo como Gemfile/Gemfile.lock ou package.json/package-lock.json [,yarn.lock] que facilita a instalação de todos os pacotes necessários e garante que você permaneça em um nível de patch muito específico é uma distinção muito significativa que é, na minha opinião, o que torna as bibliotecas de terceiros para algo tão viável.

Talvez haja algo que possa ser feito com o Nuget para resolver esse problema, mas nunca vi nenhum artigo descrevendo estratégias / padrões de gerenciamento de dependência para PowerShell. Ter a galeria é ótimo, mas se você tiver que instalar todos os pacotes necessários manualmente, isso se torna inviável para qualquer implantação significativa.

editar:
Portanto, parece que o que estou procurando _pode_ já estar disponível: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. Vou testar isso assim que tiver um momento. Se funcionar, terei de reconsiderar minha posição sobre se este deve ser um item essencial ou não. Ainda estou tendo dificuldade em conciliar isso com o fato de que JSON é uma funcionalidade central, mas suponho que possa ser considerado um "mínimo denominador comum".

@bgshacklett fez um comentário muito bom.

@ chuanjiao10 - por favor, pare de comentários prejudiciais em muitos dos problemas neste repositório, a solução correta seria não incluí-los no módulo Microsoft.PowerShell.Utility e enviá-los como um módulo separado hospedado no PowerShellGallery

Quando você diz nativamente, você quer dizer como XML ou JSON?

O pensamento atual é que YAML não deve ser incorporado ao PowerShell, em vez disso, deve ser um módulo separado que você pode atualizar sem pegar uma nova versão do PowerShell.

Se YAML fosse incorporado ao PowerShell como XML, isso seria impossível (pense em [xml] "b")

Se seguirmos a rota JSON, você terá cmdlets para trabalhar com YAML - então não realmente embutido no PowerShell, mas ainda terá as desvantagens de precisar atualizar o PowerShell para obter atualizações YAML.

Pessoalmente, embora pareça a coisa "certa" para a caixa de entrada, vou sugerir que não é realmente a coisa certa a fazer

@lzybkr Sei que dissemos que não queríamos trazer uma nova biblioteca, mas acho que isso é algo que precisamos reavaliar. Idealmente, deveríamos _também_ enviar o módulo na Galeria, mas acho que muitos cenários modernos exigem YAML agora.

Talvez não no prazo 6.0, mas devemos conversar sobre isso.

Enviar um módulo externo é muito melhor na minha opinião, pois pode ser usado em nível inferior e, IMO, é menos tarefa da equipe do PowerShell fazer isso e mais da comunidade conduzir isso com a ajuda da equipe do PowerShell para obter alta qualidade sempre que possível.

Mais uma vez, @ chuanjiao10 foi previamente decidido não colocar cmdlets YAML no PowerShell Core no # 2109 e foi corretamente rejeitado, pois também deve ser rejeitado agora.

a respeito de

unidade é força. Um americano que precisa de um carro, você o viu ir ao Wal-Mart para comprar uma roda, ir à Amazon para comprar um motor e combinar a si mesmo (faça você mesmo um carro)?

Comparar um carro com um software é uma analogia ruim, considerando que os componentes do carro vêm de muitos fornecedores diferentes e, em seguida, são empacotados em um produto utilizável, o que não é diferente dos módulos PowerShell desenvolvidos pela comunidade que podem então ser misturados e combinados e usado em scripts

Em relação a este ponto

A biblioteca principal está embutida, isso é muito importante, caso contrário, vejo que convertfrom-json, convertto-json, etc., também devem ser colocados em PowerShellGallery.

Defendi isso para o maior número possível de módulos integrados conforme # 1979 e gostaria de ver o PowerShell Core ser o mais enxuto possível, o que foi discutido posteriormente em # 5681

e re

Não discrimine YAML, não bajule JSON.

Não estou discriminando Yaml nem elogiando Json, pois ambos têm suas falhas, mas ambos têm seus usos e se eu tivesse sido capaz de influenciar a não remessa de cmdlets Json no PowerShell, teria feito exatamente o mesmo que estou fazendo aqui.

Acho que pode ser benéfico reformular um pouco essa discussão. Em particular, aqueles a favor da inclusão de YAML na linguagem central estariam dispostos a listar casos de uso específicos e por que um módulo na galeria do PowerShell é insuficiente para lidar com esse caso de uso? Nesse ponto, podemos ter uma discussão baseada em requisitos e potencialmente encontrar uma solução viável para o problema em questão.

Meu principal caso de uso é para a automação bare metal do sistema operacional e da implantação de aplicativos. Em pelo menos um caso, desejo ler um arquivo YAML que chamou meu script para entender os parâmetros.
Freqüentemente, nesses casos, tendo uma dependência de um serviço externo, sem SLA para nós, o serviço é uma grande falta de nenhum. Isso pode afetar as atividades de escalonamento da produção.

Esse é o meu caso de uso para remessa na pegada mais elementar do núcleo do PowerShell.

Agradeço a discussão animada, vamos tentar mantê-la civilizada :)

@ PowerShell / powershell-Committee discutiu isso anteriormente. Concordamos que apoiar o YAML é importante dado o quão prevalente é hoje. Também queremos ver mais módulos que enviamos atualmente no PSCore6 removidos para que você comece com uma instalação mínima do PSCore6 e então adicione o que você precisa (com metamódulos você não precisa adicionar mais de 10 módulos, apenas um por DevOps , por exemplo). Portanto, em relação ao YAML, o pensamento atual é que este deve ser um módulo separado (posso criar um repo no PowerShell org se alguém estiver pronto para começar a prototipar isso, minha equipe não tem largura de banda agora). Usar YamlDotNet (ou outra biblioteca de terceiros) está ok, uma vez que é avaliado do ponto de vista de suporte técnico, licenciamento (semelhante a como assumimos a dependência do Json.Net). No entanto, da última vez que vimos YAML e YamlDotNet, o problema é que as implementações de YAML variam amplamente e essa biblioteca não suportava tudo o que existe (mesmo alguns populares).

Vou apenas dizer que o suporte YAML é algo que eu gostaria que a equipe analisasse após o lançamento do 6.2.

@ SteveL-MSFT Você poderia comentar com base no problema e https://github.com/dotnet/corefx/issues/34578? Podemos usar YamlDotNet ou precisamos de uma API mais confiável do CoreFX?

na minha opinião é que permite que convertfrom-json, convertfrom-jaml tenham o mesmo status, seja movido ou integrado.

Tenho defendido que devemos mover os cmdlets JSON para fora do projeto. Existem algumas alterações que muitos gostariam de fazer que seriam alterações bastante significativas, mas não podem ser feitas porque os cmdlets estão vinculados ao PowerShell. Movê-los para fora do projeto nos permite fazer as principais alterações em uma nova versão principal do módulo cmdlets e fazer com que o PowerShell seja enviado com uma versão mais antiga, fornecendo compatibilidade com versões anteriores, mas permitindo que os usuários atualizem se desejarem ... No entanto, é um grande aborrecimento incluir módulos externos como este, IMO.

Prefiro que aprendamos com nossos erros com JSON e Pester do que tratar arbitrariamente o YAML da mesma maneira. Definitivamente, não deve fazer parte da funcionalidade central do PowerShell, mas deve definitivamente ter algum tipo de módulo oficialmente compatível com propriedade compartilhada entre a comunidade e a equipe PS.

Eu gosto daquela ideia. Mover os cmdlets JSON ajudaria a resolver problemas de fluxo de trabalho que existem atualmente com dependências rígidas em módulos externos.

Mas yaml é importante para administradores de sistema, desenvolvedores de script. Esses usuários precisam de comandos yaml.

Eles podem precisar deles, mas isso não significa que eles precisam ser incluídos diretamente no PowerShell, pois um módulo externo é mais do que aceitável e tem um ciclo de vida de suporte mais flexível do que qualquer coisa agrupada no repositório central.

Eu tenho que dizer que a ideia @ SteveL-MSFT de um módulo DevOps Meta é realmente o caminho certo para isso a longo prazo, pois permite que diferentes conjuntos de usuários obtenham um conjunto mais simples de pacotes que são muito mais fáceis de gerenciar como uma dependência externa do que interna, o que para mim faz muito sentido no futuro, embora devam ser metamódulos baseados em pilhas de tecnologia, porque se estou no Windows e não estou usando o anisble, por que precisaria dos cmdlets do yaml no janelas?

Embora haja um grande número de usuários no mundo do linux usando yml, conforme mencionado por @ chuanjiao10, este não é o caso no mundo do Windows, que pelo meu entendimento do uso geral do PowerShell ainda se apega amplamente ao PowerShell 5.1, já que está na caixa de entrada de seus sistemas e, embora agrupar cmdlets Yaml possa ajudar os usuários do Linux, parece-me um item adicional desnecessário para usuários do Windows, mas para tratar ambos os conjuntos de usuários da mesma forma, faz todo o sentido que acaba sendo um módulo externo que ambos os conjuntos de usuários pode utilizar conforme necessário

Alguém quer se tornar um proprietário e acompanhar esses cmdlets em um projeto separado?

@iSazonov parece que a corefx não está interessada no suporte YAML embutido. YamlDotNet parece ser a biblioteca mais popular, é licenciada pelo MIT e mantida ativamente, então eu começaria por aí. Um projeto orientado pela comunidade seria incrível e provavelmente aconteceria mais cedo do que se você deixasse para a equipe do PowerShell.

@ SteveL-MSFT parece que é por um bom motivo - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255 que eu espero que isso tenha diminuído a confiança nesta biblioteca em particular.

parece que a corefx atualmente não está interessada em suporte YAML integrado.

A equipe CoreFX pergunta sobre casos de uso. Se o projeto PowerShell disser que precisamos da API, eles considerarão a adição da API.

Um projeto orientado pela comunidade seria incrível e provavelmente aconteceria mais cedo do que se você deixasse para a equipe do PowerShell.

Oh, eu conheço apenas um desses projetos - Pester. E eu não acredito no projeto conduzido pela comunidade yaml - por que ele não apareceu nos últimos anos?
Eu considero iniciar o projeto, mas me impediu de nunca poder atingir o nível de qualidade, conformidade e segurança do código que a MSFT exige.
Acho que a MSFT nunca será capaz de confiar e usar projetos sem auditoria de segurança.
Tenho apenas uma ideia para fazer funcionar. Projetos MSFT GitHub como CoreFX e PowerShell são "propriedade da MSFT" e "dirigidos pela MSFT". O novo tipo de projeto pode ser "propriedade da MSFT", "conduzido pela comunidade" e "orientado pela MSFT". Em "orientado", quero dizer a implementação de um ambiente onde o projeto será confiável e de alta qualidade.

A Microsoft precisa agrupar o suporte YAML in-box para PowerShell Core. Claro e simples.

@brettjacobson Sim, seria simples, simples e de alta qualidade, mas a equipe MSFT não tem tantos recursos. Você está pronto para contribuir? :-)

@brettjacobson - A Microsoft não precisa agrupar o suporte YAML. Pode ser útil se o fizerem, mas não há nenhuma exigência deles para fazê-lo, nem há necessidade de fazê-lo.

Este é um pedido de recurso para algo que muitos want e acabaria por use mas não é um need crítico e, portanto, é _ improvável_ de ser priorizado, o que é exatamente o que @ SteveL-MSFT estava tentando chegar quando ele disse o seguinte

Vou apenas dizer que o suporte YAML é algo que eu gostaria que a equipe analisasse após o lançamento do 6.2.

Um projeto orientado pela comunidade seria incrível e provavelmente aconteceria mais cedo do que se você deixasse para a equipe do PowerShell.

A equipe do PowerShell não é enorme e, portanto, olhando para isso de forma realista, a melhor e mais rápida maneira de conseguir suporte para YAML será externa ao conjunto de recursos básicos do PowerShell, em vez de ser incorporado ao próprio produto.

A equipe CoreFX pergunta sobre casos de uso. Se o projeto PowerShell disser que precisamos da API, eles considerarão a adição da API.

@iSazonov IMHO nunca haverá suporte interno para YAML no CoreFX, pois ainda não houve suporte JSON completo.

Então, você vai esperar por uma "ótima" biblioteca de terceiros ou pedir a James Newton-King para criar um Newtonsoft.Yaml ? :-)

@NextTurn Teremos uma nova implementação Json (muito rápida (mais rápida do que Newton.Json) e muito flexível) no .Net Core 3.0.
A equipe CoreFX sempre adiciona uma nova API se houver grande solicitação da comunidade. Se houver muitos projetos que podem se beneficiar do YAML, eles irão adicionar. Atualmente, nenhum desses pedidos é.

O que eu não faço a cada novo pwsh sistema? Eu faço Install-Module -Name powershell-yaml .

Mongo, Kubernetes, Istio, Ansible, nomeie - eu uso. Todos esses são YAML e eu tenho modelos e transformações YAML. pwsh parece bom para DevOps e eles falam YAML.

@ dzmitry-lahoda O problema # 5681 propõe ter uma versão 'rica' do PowerShell que vem com um conjunto de módulos comuns, como, por exemplo, Pester , etc. claro vencedor entre os 2 módulos yaml disponíveis atualmente e eles estão se superando, pode ser uma decisão difícil escolher um favorito.

Vejo apenas um YAML :(

Pester , sim. Muito pesado para enviar a estrutura BDD para a linha principal, ao contrário do leitor YAML para meus aplicativos de contêiner pwsh.

Este tópico foi concluído. Qual é o módulo recomendado (ou sugerido) para uso pela Microsoft?
Os pipelines DevOps usam yaml. Toda a minha automação de implantação é construída com PowerShell. Parece que yaml e PowerShell não jogam bem. O powershell é uma escolha ruim para automação do Azure DevOps?
Preciso pensar cuidadosamente sobre meu uso / inovação futura e gostaria de receber alguma orientação.
Desde já, obrigado!

@dirkslab Você pode usar https://github.com/cloudbase/powershell-yaml

GitHub

cloudbase / powershell-yaml

PowerShell CmdLets para manipulação de formato YAML. Contribua com o desenvolvimento cloudbase / powershell-yaml criando uma conta no GitHub.

Obrigado @iSazonov , essa é a solução que estou testando no momento. A solução até agora parece funcionar bem. Provavelmente não há nada de errado em usar a solução.

Observe que usando o PowerShell-yaml você precisa aprovar um módulo não confiável. Esta é a parte que estou lutando para entender. A Microsoft recomenda o uso de pipelines yaml. A Microsoft (ou pelo menos este tópico) sugere o uso de módulo de terceiros para que você possa integrar a configuração do yaml com o PowerShell, mas não endossa ou recomenda nenhum. Como você explica isso logicamente para a empresa.
Minha experiência até agora sempre foi que, se você não usar soluções endossadas pela Microsoft, isso silenciaria qualquer suporte ou entendimento da Microsoft para seus problemas de solução (isso não importa se a parte sem suporte tocar em algo que esteja causando problemas). O simples fato de você ter uma parte sem suporte geralmente resulta em nenhum suporte / responsabilidade.
Talvez as coisas tenham mudado nesta era do OpenSource. Uma resposta oficial simples e orientação da Microsoft me deixariam à vontade e me ajudariam a entender.

Agradecemos sua resposta. Saudações.

@dirkslab Acho que o gerente da sua conta MSFT é a pessoa certa para perguntar sobre a política de suporte.

Equipe CoreFX pergunta sobre casos de uso

Além dos benefícios óbvios que o yaml está ao nosso redor em CI / CD hoje e vários sistemas de configuração, o benefício adicional de ConvertTo-Yaml é representar HashTable nasted em formato legível por humanos , ao contrário de ConvertTo-Json que temos que usar agora o que torna a saída não muito legível.

Eu uso Write-HashTable entretanto, mas seria ótimo ter OTB.

Eu odeio yaml, realmente odeio isso. No entanto, existem algumas facetas que valem a pena a equipe de MS considerar:

1. Tornou-se a linguagem de fato do CI: docker-compose.yaml, ansible, kuber, k8s, github, circle, azure, ... E parece rastejar de CI para os projetos que o usam.

$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)

Ter este navio com o PowerShell seria transformador na evangelização para grupos de IC.
"Se mudarmos para ms PowerShell, podemos automaticamente" -> "Diga-me mais?"
vs
"Se mudarmos para ms powershell e baixarmos alguns scripts da galeria" -> "não"

1. Realmente, isso é a propósito, mas yaml é um superconjunto de json, de forma que json é uma forma abreviada de yaml, um analisador yaml eficiente é um analisador json eficiente,

Isso pode ser reconsiderado para 7.1? Também estou tendo problemas com o uso de um módulo não confiável e algo assim, DevsOpsy deve realmente ser nativo do PowerShell.

IMHO, YAML é tão popular quanto JSON e CSV, e não ter conversores de caixa de entrada para YAML no PowerShell é meio triste. Ter conversores YAML na caixa de entrada também garante que seu comportamento esteja em pé de igualdade com os conversores JSON, o que não é o caso com os módulos da comunidade.

Não me interpretem mal - eu aprecio que as pessoas criem módulos para a comunidade, mas no estado atual do mundo, a conversão YAML é um jogo decisivo - não esperamos que as pessoas baixem módulos de terceiros para conversão JSON.