Powershell: ConvertFrom-Yaml, ConvertTo-Yaml

Tuvimos una discusión similar sobre el aspecto DSC ,
permitiéndonos cambiar los archivos de configuración basados ​​en json, queríamos tener opciones para modificar archivos basados ​​en xml, archivos basados ​​en YAML, archivos basados ​​en INI que admitan intercambios de RegEx desde los cmdlets de manipulación de texto.

La falta de soporte existente en PS significa que tenemos que trabajar duro para obtener dicha capacidad.
Ha estado en espera de la contribución de la comunidad, pero si se integrara en PS, también sería mucho más fácil para la parte DSC.

Cuando dices de forma nativa, ¿te refieres a XML o JSON?

La idea actual es que YAML no debe integrarse en PowerShell en absoluto, sino que debe ser un módulo separado que puede actualizar sin tener que adquirir una nueva versión de PowerShell.

Si YAML estuviera integrado en PowerShell como XML, sería imposible (piense en [xml] " b ")

Si optamos por la ruta JSON, tendría cmdlets para trabajar con YAML, por lo que no está realmente integrado en PowerShell, pero aún tendría los inconvenientes de tener que actualizar PowerShell para obtener actualizaciones de YAML.

@lzybkr Sé que dijimos que no queríamos traer una nueva biblioteca, pero creo que esto es algo que podríamos necesitar reevaluar. Idealmente, también deberíamos enviar el módulo a la Galería, pero creo que una TONELADA de escenarios modernos requieren YAML ahora.

Quizás no en el plazo de 6.0, pero deberíamos hablar de ello.

@ArieHein : tengo algunas funciones simples que guardan y recuperan una matriz hash en el registro. Solo maneje REG_SZ, pero para un conjunto simple de configuraciones es suficiente, avíseme si desea una copia.

Me equivoqué cuando dije "nativo" - principalmente quise decir "integrado" - no me molestaría si fueran módulos de script incluidos que pudieran actualizarse.

Nuestra primera discusión # 2109

@iSazonov - ¡ah, sí, ya veo!

Noté la referencia al soporte de AWS de YAML en el hilo. He estado convirtiendo algunas plantillas y he encontrado que esto es útil: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov gracias por el puntero, no pude encontrarlo por alguna razón. Pero recuérdalo bien.

Al releer ese hilo original, creo que definitivamente deberíamos implementar los cmdlets en algún momento en el futuro y enviarlos a la Galería. En función de su calidad y la utilidad percibida por las personas (junto con algunos trabajos de refactorización que esperamos hacer después de 6.0.0), podemos realizar la llamada desde la bandeja de entrada frente a la de solo la galería.

Tenemos Yaml en https://github.com/PowerShell/platyPS

sí, sería increíble tener esto, terminó usando https://github.com/awslabs/aws-cfn-template-flip para convertir

@MattTunny ¡ Bienvenido a contribuir! :-)

Hay una voz de usuario de Windows Server abierta para votar por ella :-)

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

Esto definitivamente debería ser parte de la biblioteca nativa de PS 6.1. Tantas cosas en estos días están en YAML.

Ahora hay módulos psyaml y powershell-yaml en PSGallery, pero ambos ni siquiera pueden realizar un viaje de ida y vuelta a un archivo YAML desde una definición de compilación VSTS. No me importa si el módulo está integrado en PowerShell o es un módulo de PSGallery.

Me pregunto si el problema principal aquí es la forma torpe en que implementamos los módulos. Hoy, debe encontrar, confiar e instalar un módulo antes de poder usarlo. Compare esto con la forma (aparentemente) hábil en que Javascript hace var m = require('mymodule') . Tal vez deberíamos tener alguna forma de hacer lo que hace DSC, pero para PowerShell nativo. En DSC, cuando se hace referencia a un módulo en una configuración, se descarga e instala automáticamente en el nodo de destino sin esfuerzo manual. Hacer que los módulos críticos pero no esenciales estén disponibles de esa manera debería eliminar los argumentos de "debería ser parte del núcleo". Y para los nodos que están desconectados de la red, podríamos tener una herramienta que agrupa las dependencias en un script en un archivo que luego se implementa en el objetivo. Así es como funciona la extensión de recursos de Azure DSC: hay una herramienta que escanea un script para averiguar los módulos requeridos, luego crea un archivo zip que contiene todo lo necesario y lo publica en un blob. La extensión de recursos de Azure luego extrae este blob, instala los módulos y ejecuta el script.

Para algo que es tan importante, realmente no quiero depender de una biblioteca de terceros a menos que tenga alguna forma de venderla. Es demasiado fácil para los desarrolladores externos romper ecosistemas enteros (consulte https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

Dejando de lado los problemas más amplios, actualmente no hay un buen módulo YAML para PowerShell, como señaló @bergmeister . Esta es una necesidad para un lenguaje que está fuertemente enfocado hacia la automatización. Los archivos de configuración basados ​​en YAML son muy populares ahora y es muy difícil evitarlos incluso si no tiene que lidiar con las opiniones de un equipo para hacerlo. Piense en el razonamiento detrás de la inclusión de XML y JSON como partes centrales del lenguaje. El caso de YAML realmente no es tan diferente.

@bgshacklett Por lo que he escuchado de los chicos de Puppet, simplemente no hay buenos analizadores de YAML :-)

¿Es el analizador platyPS lo suficientemente bueno?

@vors ¿Hay una forma sencilla de reutilizar el analizador platyPS YAML en el repositorio de PowerShell Core?

Prefiero la idea de un módulo oficial separado en la Galería de PowerShell como dice @lzybkr porque sería posible usarlo en versiones anteriores de PowerShell y podría tener sus propias versiones. Eso sería como el módulo sqlserver . @BrucePay si fuera una página de la Galería PowerShell con módulos propios de Microsoft, sería más fácil de encontrar y todos sabrían que pueden confiar en ellos.

Pero entendería si estuviera respaldado en Powershell como XML y JSON.

Lo importante es que existen funciones oficiales ConvertFrom-YAML y ConvertFrom-YAML porque YAML es un formato muy utilizado para archivos de configuración y no debería ser un módulo de terceros, como señala @bgshacklett .

Hice una entrada de blog probando y comparando los dos módulos que encontré que funcionan con archivos YAML: PSYaml y powershell-yaml .

Tienen diferentes comportamientos porque internamente están usando diferentes objetos:

| módulo | mapeos | secuencias |
| --------- |: -------------- | ----------- |
| PSYaml | OrderedDictionary | Array |
| powershell-yaml | Hastable | Lista |

Creo que necesitamos un ConvertFrom-YAML y ConvertFrom-YAML estándar .

En realidad, ConvertFrom-Yaml en powershell-yaml usa OrderedDictionary al convertir con el parámetro -ordered .
He estado usando este módulo con éxito durante un tiempo (en mi módulo Datum para datos de configuración DSC y con yamls de cocina), pero no tengo una definición de compilación vsts para probar.

Tenga en cuenta que la forma correcta de llamarlo es: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (la gente suele perder el -Raw ).

Me pregunto por qué necesitaríamos un módulo _oficial_ de Microsoft, poner aún más sobrecarga en MSFT y reinventar la rueda ... Tal vez intentar contribuir a uno existente primero, agregar pruebas para evitar la regresión, problemas abiertos para asegurarse de que el propietario conozca el problemas es un mejor enfoque ...
Sabes lo que sucede cuando intentas crear un estándar a partir de las 99 implementaciones existentes ...

Y sí, sería mejor fuera del idioma, estoy de acuerdo en que la gestión de dependencias podría ser mejor, aunque agrupar todo en PS no es una solución.
El problema general de npm también es una falla en el proceso. Bifurcar y volver a publicar lo solucionó en poco tiempo, la creación de aplicaciones a partir de la última versión de Internet fue la razón por la que rompió tantas aplicaciones en vivo.

Estoy de acuerdo con @gaelcolas.Creo que es mejor que todos trabajen con los propietarios de un módulo comunitario existente para aumentar y garantizar la calidad.

Solo agregaré que las pruebas para tal proyecto deberían incluir trabajar con una gran cantidad de archivos YAML del mundo real para cosas como AppVeyor, Travis CI, VSTS, AWS CloudFormation, etc. Para mi propia experiencia con la deserilización YAML, he tenido poco éxito con una solución que funciona universalmente y, en última instancia, he tenido que reinventar la rueda varias veces. En ese sentido, estoy de acuerdo con @BrucePay "simplemente no hay buenos analizadores de YAML".

Estamos hablando de este módulo platyPS porque ya se usa activamente en el entorno de ayuda de PowerShell. Supongo que nadie de MSFT puede decir qué tan bueno es este módulo debido al Código de Conducta. Pueden rechazarlo en silencio o mejorarlo.
Y aunque hemos estado hablando de esto hace mucho tiempo, no veo cómo podríamos usar los componentes de este módulo aquí de una manera simple.
Quizás @adityapatwardhan y @ SteveL-MSFT abrirán sus planes y cronograma, especialmente porque el nuevo Help RFC ya se encuentra en la etapa de experimento.

Mi opinión personal es que prefiero que más módulos de la comunidad tengan éxito y se conviertan en estándar de facto que requerir módulos "oficiales" de Msft.

@iSazonov Una cosa es tener una solución que funcione para serializar / deserializar un esquema bien definido. Otra muy distinta es tener una solución que funcione en general con todos los esquemas que cumplen con YAML.

Entiendo el deseo de MSFT de reutilizar proyectos comunitarios para reducir costos. Pero la situación es, de hecho, que MSFT puede no hacer uso de tantos proyectos comunitarios:

• muchos tienen un código incorrecto, no tienen confianza
• muchos proyectos son una sola persona

MSFT ha publicado especificaciones de Powershell hace más de 10 años, pero nadie lo ha portado hasta que lo hizo MSFT.
El proyecto OpenSSL existe desde hace muchos años, pero nadie lo ha portado a Windows mientras que MSFT no lo ha hecho.
MSFT reveló muchos miles de interfaces API, pero ¿cuántas de ellas se portaron a Unix?
¿Lo interesante de por qué la empresa lanzó su proyecto .Net Core en lugar de reutilizar Mono?
PowerShell ya hace año y medio es un proyecto de código abierto, pero veo que en este repositorio solo una persona de la comunidad hace aportación sistemática en el código @markekraus y solo una persona hace análisis sistemático @ mklement0.
No creo que si dividimos el proyecto en partes, obtendremos más contribuciones.
No creo que la situación cambie mañana. No contaría con eso.

@markekraus Espero mucho en http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov hace puntos importantes sobre el soporte, la confianza y el mantenimiento de módulos de terceros. Algún módulo de terceros puede convertirse en un éxito y madurar como, por ejemplo, Pester.
Sin embargo, no se debe asumir que un gran módulo YAML evolucionará por sí solo durante los próximos años. La realidad es que la mayoría de los módulos son publicados por autores que resolvieron un problema en particular e hicieron la buena obra de publicar su código base genérico. Así es como terminamos con 2 módulos que tienen como objetivo resolver el mismo problema. Idealmente, uno necesitaría fusionarlos para enfocar los esfuerzos, de lo contrario, se separarán más en el futuro o simplemente se volverán obsoletos y pronto habrá más módulos publicados por otras personas.
El problema subyacente de tener un analizador adecuado indica que se necesita un trabajo preliminar básico (y sustancial en términos de esfuerzo) para tener un buen módulo YAML.
No soy un experto en YAML, pero ¿es esto solo un problema de la especificación suelta del lenguaje en sí o la interpretación específica de varios sistemas como VSTS o AppVeyor o es solo la falta de un buen analizador?
Me pareció frustrante escribir YAML en VSCode y solo cuando lo ejecuté en VSTS obtuve un error de que al analizador VSTS no le gusta ...

Para mí, esta conversación es un ejemplo del problema de "arquitectura / curación de código" del código abierto.

El código abierto proporciona buenas ideas de siembra y bases de código, pero si no se le presta atención a la arquitectura cuando se adopta como la solución más general, entonces son 10 años de correcciones de errores para elementos que podrían haberse solucionado en una revisión de diseño decente. .

En los casos reales de @bergmeister "éxitos maduros", a menudo es un mantenedor activo el que ha asumido la misión de generalizar la base del código. Pero no se puede garantizar que eso suceda.

Creo que algunos de nosotros estamos diciendo: "El soporte YAML es como el soporte para escribir archivos, es fundamental, debe diseñarse de la misma manera => con la intención de ser el estándar de oro para esa funcionalidad".

La combinación de 1) el atributo semi-arquitectónico del código abierto junto con 2) la naturaleza central de YAML que parece hacer que muchos de nosotros impulsemos el enfoque altamente arquitectónico que sabemos que los desarrolladores de Microsoft PowerShell aplican a su trabajo. No es necesariamente una derivación de todas las otras cosas interesantes con las que el código abierto puede ayudarnos.

Puntos muy válidos sobre la madurez del software. No he examinado de cerca los dos módulos enumerados aquí, ni tampoco yamldotnet para hacer una opinión. Algo que podemos ver cuando comenzamos a planificar la versión 6.2.0

No me malinterpretes, valoro la experiencia y el enfoque sistemático del equipo de PowerShell y los desarrolladores de MSFT, solo creo que está mal que intenten llenar todos los vacíos con un módulo de su propio MSFT estampado ... no escalar (y ya hemos visto el problema con los recursos DSC).
Aumentar la dependencia de los módulos proporcionados por MSFT es frágil y no ayuda a hacer crecer la comunidad ni la diversidad del ecosistema.
Estoy a favor de que MSFT contribuya a proyectos de código abierto para compartir su experiencia y ayudar a mejorar las prácticas y la calidad, sin crear dependencia de ellos (¡porque ya sabes, ardillas ...!).
El _MSFT como proveedor único de cosas aprobadas_ es un modelo antiguo sobre el que ya luchan por educar, y no está ayudando a la comunidad a fomentar este enfoque (es decir, _Esperaré, o me quejaré, en Microsoft por no resolver el problema que tengo_ tipo de actitud en el ecosistema OSS).

Estoy de acuerdo en que el soporte de YAML es fundamental, en lugar de que el equipo de PS vuelva a escribir desde cero, ¿por qué no ayudar a los mantenedores de proyectos existentes a mejorar y darles la oportunidad de fusionar proyectos y escuchar de ellos lo que se necesitaría? Un poco como un aprendizaje / tutoría del equipo de PS en los módulos de funcionalidad principal.
Simplemente reescribir un nuevo módulo suena como la reacción de un ingeniero para resolver un problema que no es un problema de ingeniería. Reescribir un módulo YAML es una tarea de ingeniería _fácil_ para el equipo de PS, pero no (ayudaría) a solucionar el problema de madurez de la comunidad, ni daría el incentivo adecuado.
Sin embargo, si Yaml es el elemento estratégico para abordar esto es la decisión de MSFT :)

@bergmeister

Prologaré esto diciendo que no soy un experto en YAML. Hice una investigación sobre esto cuando quería hornear algunas configuraciones de AppVeyor como yaml en mi propio canal de franken. Observé cómo una docena de proyectos de C # consumían YAML. Dado que los proyectos de PowerShell usan YamlDotNet, solo puedo asumir que no es más fácil. Aunque al menos he jugado con PSYaml y powershell-yaml y he analizado menos de cerca algunos proyectos de PowerShell que los usan.

No soy un experto en YAML, pero ¿es esto solo un problema de la especificación suelta del lenguaje en sí o la interpretación específica de varios sistemas como VSTS o AppVeyor o es solo la falta de un buen analizador?

Sospecho que la naturaleza de YAML es legible por humanos a expensas de que las máquinas lo puedan leer más fácilmente. Este paradigma de legibilidad primero se extiende a la forma en que los autores de YAML escriben sus archivos YAML. Aunque el YAML resultante cumple con la especificación YAML, se analiza de tal manera que no se puede usar en el código sin usar el objeto deserializado como intermediario de un objeto realmente útil.

Es decir, que el 90% de las veces la deserialización de YAML a un Objeto no es el problema, sino el diseño / arquitectura de datos. El otro 10% del tiempo _es_ problemas de análisis sintáctico para los que sólo puedo atribuirme a "YAML es difícil de analizar, hombre". Sin embargo, los objetos deserializados a menudo son solo un poco más útiles que la expresión regular de lo que está buscando ...

Como ejemplo, las cadenas seguras en AppVeyor.yml

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

powershell-yaml y YamlDotNet convierten esto en un objeto, pero buena suerte usándolo sin un montón de lógica. Una vez que tenga esa lógica, bueno para este esquema, pero ¿qué pasa con otro?

Algunos de estos mismos problemas de diseño de datos plagan JSON, pero es (en mi experiencia y opinión) mucho más fácil hacer modelos que puedan solucionar esas deficiencias debido a la naturaleza más rígida de JSON. Intentar hacer modelos para cualquiera de los deserializadores YAML mencionados en este hilo es una pesadilla siempre que sea posible.

Por supuesto, los modelos no son una característica disponible actualmente en los cmdlets JSON, aunque realmente me gustaría agregarlos. Si tuviera algo que decir en el módulo / cmdlets YAML "oficial", lo pondría como una característica "imprescindible". Es una oportunidad perdida, especialmente con la adición de clases de PowerShell en v5.

En mi opinión, solo tener cadenas YAML en un objeto no es lo suficientemente bueno. Eso parece fácil (al menos el 90% de las veces). El truco consiste en convertir cadenas YAML en objetos _useful_. Eso requiere cierta flexibilidad de la solución. Pero esa flexibilidad también debe ser algo accesible y no requerir que @IISResetMe y @lzybkr estén allí para brindarle consejos de serialización ...

En ese sentido, no he visto nada que funcione en un ámbito general. Los proyectos adoptan las soluciones disponibles y luego usan su salida como intermediarios para objetos realmente útiles (lo que lleva a un montón de reinventaciones de ruedas que probablemente deberían hornearse en sentido ascendente). O bien, los proyectos comprometen la legibilidad de YAML para facilitar el análisis de YAML a objetos.

@gaelcolas

Estoy de acuerdo en que el soporte de YAML es fundamental, en lugar de que el equipo de PS vuelva a escribir desde cero, ¿por qué no ayudar a los mantenedores de proyectos existentes a mejorar y darles la oportunidad de fusionar proyectos y escuchar de ellos lo que se necesitaría?

Pregúntese por qué MSFT inició el proyecto .Net Core en lugar de continuar con Mono muchos años después.

MSFT también es una comunidad. Y como cualquier comunidad tiene los mismos problemas de interacción con otras comunidades.

Para el contexto, no estoy insinuando que ningún trabajo se haga desde cero (el código podría adoptarse), pero luego debería analizarse desde una perspectiva de arquitectura de desarrollo de sistemas antes de mejorarlo. Incluso podría ser de código abierto después de esa revisión y relanzamiento.

Mi punto es tener una revisión arquitectónica significativa y una corrección por parte de un equipo que comprende a fondo los matices del código central que se aprovechará prácticamente en todas partes.

Otro modelo que siempre vale la pena considerar es adquirir / contratar / segundo. Sobre esta base, se hace un esfuerzo para llegar a términos comerciales con uno o más miembros de la comunidad / empresas para contratar sus servicios para un ciclo de desarrollo facilitado / liderado por MSFT para renovar y (de alguna manera) integrar / conectar el producto (s) . Esto se hizo con éxito con Xamarin, que envió el proyecto a Net Foundation, lo autorizó con el MIT y reclutó / contrató / involucró a recursos clave como Miguel de Icaza y Nat Friedman a través de Xamarin. Algunos se quejan de que se trata de una traición de código abierto. Pero crea incentivos positivos para que las personas y las pequeñas empresas conciban y desarrollen proyectos que luego podrían ser aptos para una adopción e integración generalizada en al menos un ecosistema importante. Ciertamente, se prefiere saltar directamente a un rehacer interno que copia todo el concepto y la funcionalidad y muchas de las ideas, pero descarta a los creadores y (aparentemente) el código.

@iSazonov perdón por una respuesta tardía, no, el analizador yaml platyPS no es bueno: solo admite pares de valores clave. También usamos YamlDotNet para generar yaml allí.

Con respecto al sentimiento de mantener esto fuera del conjunto de características principales: hay una diferencia muy significativa en cómo PowerShell maneja las dependencias en comparación con, digamos, Ruby, Python o Node.js.

Cada uno de estos lenguajes tiene herramientas de gestión de dependencias (bundler, pip, npm / yarn) que facilitan la gestión de dependencias externas y, lo que es más importante, reproducible. Tener algo como Gemfile/Gemfile.lock o package.json/package-lock.json [,yarn.lock] que facilita la instalación de todos los paquetes requeridos y garantiza que se quede en un nivel de parche muy específico es una distinción muy importante que, en mi opinión, es lo que hace que las bibliotecas de terceros para algo tan fundamental sea factible.

Quizás haya algo que se pueda hacer con Nuget para resolver este problema, pero nunca he visto ningún artículo que describa estrategias / patrones de administración de dependencias para PowerShell. Tener la galería es genial, pero si tiene que instalar todos los paquetes necesarios manualmente, se vuelve inviable para cualquier implementación significativa.

editar:
Así que parece que lo que estoy buscando _may_ ya esté disponible: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. Probaré esto tan pronto como tenga un momento. Si funciona, tendré que reconsiderar mi posición sobre si este debería ser un elemento central o no. Todavía tengo dificultades para conciliarlo con el hecho de que JSON es una funcionalidad básica, pero supongo que podría considerarse un "mínimo común denominador".

@bgshacklett tiene un punto muy bueno.

@ chuanjiao10 : detenga los comentarios disruptivos en muchos de los problemas de este repositorio, la solución correcta no sería incluirlos en el módulo Microsoft.PowerShell.Utility y, de hecho, enviarlos como un módulo separado alojado en PowerShellGallery

Cuando dices de forma nativa, ¿te refieres a XML o JSON?

La idea actual es que YAML no debe integrarse en PowerShell en absoluto, sino que debe ser un módulo separado que puede actualizar sin tener que adquirir una nueva versión de PowerShell.

Si YAML estuviera integrado en PowerShell como XML, sería imposible (piense en [xml] "b")

Si optamos por la ruta JSON, tendría cmdlets para trabajar con YAML, por lo que no está realmente integrado en PowerShell, pero aún tendría los inconvenientes de tener que actualizar PowerShell para obtener actualizaciones de YAML.

Personalmente, si bien se siente como lo "correcto" en la bandeja de entrada, sugeriré que en realidad no es lo correcto.

@lzybkr Sé que dijimos que no queríamos traer una nueva biblioteca, pero creo que esto es algo que podríamos necesitar reevaluar. Idealmente, deberíamos _también_ enviar el módulo en la Galería, pero creo que una TONELADA de escenarios modernos requieren YAML ahora.

Quizás no en el plazo de 6.0, pero deberíamos hablar de ello.

En mi opinión, enviar un módulo externo es mucho mejor, ya que se puede usar en un nivel inferior y, en mi opinión, es menos el trabajo del equipo de PowerShell hacer esto y más la comunidad lo impulsa con la ayuda del equipo de PowerShell para obtener alta calidad cuando sea posible.

Una vez más, @ chuanjiao10 , se decidió anteriormente no poner los cmdlets YAML en PowerShell Core en # 2109 y fue rechazado con razón en ese momento, ya que también debería rechazarse ahora.

respecto a

la Unión hace la fuerza. Un estadounidense que necesita un automóvil, ¿lo ha visto ir a Wal-Mart a comprar una rueda, ir a Amazon a comprar un motor y combinarlo (hacer un auto)?

Comparar un automóvil con un software es una especie de mala analogía, considerando que los componentes del automóvil provienen de muchos proveedores diferentes y luego se empaquetan en un producto utilizable, que no es diferente de los módulos PowerShell desarrollados por la comunidad que luego se pueden mezclar y combinar y usado en scripts

Respecto a este punto

La biblioteca principal está integrada, esto es muy importante; de ​​lo contrario, veo que convertfrom-json, convertto-json, etc., también debe colocarse en PowerShellGallery.

He abogado por esto para tantos de los módulos integrados como sea posible según # 1979 y me gustaría ver que PowerShell Core sea lo más delgado posible, lo que se ha comenzado a discutir más a fondo en # 5681

y re

No discrimine a YAML, no adule JSON.

No estoy discriminando a Yaml ni halagando a Json, ya que ambos tienen sus defectos pero ambos tienen sus usos y si hubiera podido influir en no enviar los cmdlets de Json en PowerShell, habría hecho exactamente lo mismo que estoy haciendo aquí.

Creo que puede ser beneficioso replantear un poco esta discusión. En particular, ¿aquellos que están a favor de que YAML se incluya en el lenguaje central estarían dispuestos a enumerar casos de uso específicos y por qué un módulo en la galería de PowerShell es insuficiente para abordar dicho caso de uso? En ese punto, podemos tener una discusión basada en requisitos y potencialmente encontrar una solución viable para el problema en cuestión.

Mi caso de uso principal es la automatización completa del sistema operativo y la implementación de aplicaciones. En al menos un caso, quiero leer un archivo YAML que llamó a mi script para comprender los parámetros.
Con frecuencia, en estos casos, tener una dependencia de un servicio externo que no tiene SLA para nosotros es un gran no-no. Puede afectar las actividades de escalado de la producción.

Ese es mi caso de uso para el envío en la huella más elemental del núcleo de PowerShell.

Aprecio la animada discusión, tratemos de mantenerla civilizada :)

@ PowerShell / powershell-Committee había discutido esto anteriormente. Estamos de acuerdo en que apoyar a YAML es importante dado lo común que es hoy. También queremos ver más módulos que enviamos actualmente en PSCore6 para que comience con una instalación mínima de PSCore6 y luego agregue lo que necesita (con metamódulos no necesita agregar más de 10 módulos, solo uno por DevOps , por ejemplo). Entonces, con respecto a YAML, el pensamiento actual es que este debería ser un módulo separado (puedo crear un repositorio en la organización de PowerShell si alguien está listo para comenzar a crear un prototipo de esto, mi equipo no tiene el ancho de banda en este momento). El uso de YamlDotNet (u otra biblioteca de terceros) está bien una vez que se evalúa desde el punto de vista de la tecnología, las licencias y el soporte (similar a cómo tomamos la dependencia en Json.Net). Sin embargo, la última vez que vimos YAML y YamlDotNet, el problema es que las implementaciones de YAML varían ampliamente y esa biblioteca no es compatible con todo lo que existe (incluso algunas populares).

Solo diré que la compatibilidad con YAML es algo que me gustaría que el equipo examinara después de la versión 6.2.

@ SteveL-MSFT ¿Podría comentar en función del problema y https://github.com/dotnet/corefx/issues/34578? ¿Podríamos usar YamlDotNet o necesitamos una API más confiable de CoreFX?

En mi opinión, deje que convertfrom-json, convertfrom-jaml tengan el mismo estado, ya sea que se mueva o se incorpore.

He estado defendiendo que deberíamos sacar los cmdlets JSON del proyecto. Hay bastantes cambios que a muchos les gustaría hacer que serían cambios bastante importantes, pero no se pueden realizar porque los cmdlets están vinculados a PowerShell. Sacarlos del proyecto nos permite realizar los cambios importantes en una nueva versión principal del módulo de cmdlets y hacer que PowerShell se envíe con una versión anterior que proporciona compatibilidad con versiones anteriores, pero permite a los usuarios actualizar si lo desean ... Sin embargo, es una gran molestia para incluir módulos externos como este, en mi opinión.

Preferiría que aprendamos de nuestros errores con JSON y Pester que tratar arbitrariamente a YAML de la misma manera. Definitivamente no debería ser parte de la funcionalidad principal de PowerShell, pero definitivamente debería tener algún tipo de módulo compatible oficialmente con propiedad compartida entre la comunidad y el equipo de PS.

Me gusta esa idea. Mover los cmdlets JSON ayudaría a descubrir problemas de flujo de trabajo que existen actualmente con dependencias estrictas en módulos externos.

Pero yaml es importante para administradores de sistemas, desarrolladores de scripts. Estos usuarios necesitan comandos yaml.

Es posible que los necesiten, pero eso no significa que deban incluirse directamente en PowerShell, ya que un módulo externo es más que aceptable y tiene un ciclo de vida de soporte más flexible que cualquier cosa incluida en el repositorio central.

Debo decir que la idea de @ SteveL-MSFT de un módulo DevOps Meta es realmente la forma correcta para esto a largo plazo, ya que esto permite que diferentes conjuntos de usuarios obtengan un conjunto más simple de paquetes que son mucho más fáciles de administrar. como una dependencia externa que como una interna, lo que para mí tiene mucho sentido en el futuro, aunque deberían ser metamódulos basados ​​en pilas de tecnología porque si estoy en Windows y no estoy usando anisble, ¿por qué necesitaría cmdlets yaml en ventanas?

Si bien hay una gran cantidad de usuarios en el mundo de Linux que usan yml como lo menciona @ chuanjiao10, este no es el caso en el mundo de Windows, que según mi comprensión del uso general de PowerShell todavía se adhiere en gran medida a PowerShell 5.1, ya que está en la bandeja de entrada de sus sistemas , y aunque los cmdlets de Yaml pueden ayudar a los usuarios de Linux, me parece un elemento empaquetado adicional innecesario para los usuarios de Windows, pero para tratar a ambos conjuntos de usuarios de la misma manera, tiene mucho sentido que termine siendo un módulo externo que ambos conjuntos de usuarios puede utilizar según sea necesario

¿Hay alguien que quiera convertirse en propietario y acompañar estos cmdlets en un proyecto independiente?

@iSazonov parece que corefx actualmente no está interesado en la compatibilidad con YAML incorporada. YamlDotNet parece ser la biblioteca más popular, tiene licencia del MIT y se mantiene activamente, así que empezaría por ahí. Un proyecto impulsado por la comunidad sería increíble y probablemente sucedería antes que si lo dejara en manos del equipo de PowerShell.

@ SteveL-MSFT parece que es por una buena razón: https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255 que espero que esto haya reducido la confianza en esta biblioteca en particular.

Parece que corefx actualmente no está interesado en la compatibilidad con YAML incorporada.

El equipo de CoreFX pregunta sobre casos de uso. Si el proyecto PowerShell dice que necesitamos la API, considerarán agregar la API.

Un proyecto impulsado por la comunidad sería increíble y probablemente sucedería antes que si lo dejara en manos del equipo de PowerShell.

Oh, solo conozco uno de esos proyectos: Pester. Y no creo en el proyecto impulsado por la comunidad yaml, ¿por qué no ha aparecido en los últimos años?
Considero comenzar el proyecto pero me detuvo que nunca podré alcanzar el nivel de calidad, cumplimiento y seguridad del código que requiere MSFT.
Supongo que MSFT nunca podrá confiar y utilizar proyectos sin una auditoría de seguridad.
Solo tengo una idea para que funcione. Los proyectos de MSFT GitHub como CoreFX y PowerShell son "propiedad de MSFT" y "impulsados ​​por MSFT". El nuevo tipo de proyecto podría ser "propiedad de MSFT", "impulsado por la comunidad" y "guiado por MSFT". Bajo "mentorado" me refiero a la implementación de un entorno donde el proyecto será confiable y de alta calidad.

Microsoft necesita incluir compatibilidad con YAML en la caja para PowerShell Core. Simple y llanamente.

@brettjacobson Sí, sería sencillo, sencillo y de alta calidad, pero el equipo de MSFT no tiene tantos recursos. ¿Estás listo para contribuir? :-)

@brettjacobson : Microsoft no necesita incluir compatibilidad con YAML. Puede ser útil si lo hicieran, pero no hay ningún requisito de que lo hagan ni es necesario hacerlo en absoluto.

Esta es una solicitud de función para algo que muchos want y en última instancia use pero no es un need crítico y, por lo tanto, es _ improbable_ que se priorice, que es exactamente lo que @ SteveL-MSFT estaba tratando de llegar cuando dijo lo siguiente

Solo diré que la compatibilidad con YAML es algo que me gustaría que el equipo examinara después de la versión 6.2.

Un proyecto impulsado por la comunidad sería increíble y probablemente sucedería antes que si lo dejara en manos del equipo de PowerShell.

El equipo de PowerShell no es enorme y, por lo tanto, al considerar esto de manera realista, la forma mejor y más rápida de poder obtener soporte para YAML será externa al conjunto de características principales de PowerShell, en lugar de integrarse en el producto en sí.

El equipo de CoreFX pregunta sobre casos de uso. Si el proyecto PowerShell dice que necesitamos la API, considerarán agregar la API.

@iSazonov En mi

Entonces, ¿esperará una biblioteca de terceros "excelente" o le pedirá a James Newton-King que cree un Newtonsoft.Yaml ? :-)

@NextTurn Obtendremos una nueva implementación de Json (muy rápida (más rápida que Newton.Json) y muy flexible) en .Net Core 3.0.
El equipo de CoreFX siempre agrega una nueva API si hay una gran solicitud de la comunidad. Si hay muchos proyectos que pueden beneficiarse de YAML, se agregarán. Actualmente no hay solicitudes de este tipo.

¿Qué hago con cada nuevo sistema pwsh ? Yo hago Install-Module -Name powershell-yaml .

Mongo, Kubernetes, Istio, Ansible, asígnele el nombre, yo uso. Todos estos son YAML y tengo plantillas y transformaciones YAML. pwsh parece bueno para DevOps y hablan YAML.

@ dzmitry-lahoda El número 5681 propone tener una versión 'enriquecida' de PowerShell que se envía con un conjunto de módulos comunes como, por ejemplo, Pester , etc. Por favor publique en este número, pero dado que parece no haber claro ganador entre los 2 módulos yaml disponibles actualmente y se están golpeando entre sí, podría ser una decisión difícil elegir un favorito.

Solo veo un YAML :(

Pester , sí. Demasiado pesado para enviar el marco BDD a la línea principal, a diferencia del lector YAML para mis aplicaciones de contenedores pwsh.

¿Ha concluido este hilo? ¿Cuál es el módulo recomendado (o sugerido) para usar por Microsoft?
Las canalizaciones de DevOps utilizan yaml. Toda la automatización de mi implementación está construida con powershell. Parece que yaml y powershell no juegan bien. ¿Es powershell una mala elección para la automatización de Azure DevOps?
Necesito pensar detenidamente en mi uso / innovación futuros y agradecería alguna orientación.
¡Gracias por adelantado!

@dirkslab Podría usar https://github.com/cloudbase/powershell-yaml

GitHub

cloudbase / powershell-yaml

PowerShell CmdLets para la manipulación del formato YAML. Contribuya al desarrollo de cloudbase / powershell-yaml creando una cuenta en GitHub.

Gracias @iSazonov , esa es la solución con la que estoy probando en este momento. La solución hasta ahora parece funcionar bien. Probablemente no haya nada de malo en usar la solución.

Tenga en cuenta que al usar powershell-yaml debe aceptar un módulo que no es de confianza. Esta es la parte que estoy luchando por entender. Microsoft recomienda usar canalizaciones yaml. Microsoft (o al menos este hilo) sugiere usar un módulo de terceros para que pueda integrar la configuración de yaml con powershell, pero no respalda ni recomienda ninguno. ¿Cómo se lo explica lógicamente a la empresa?
Mi experiencia hasta ahora siempre ha sido que si no usa las soluciones respaldadas por Microsoft, eso silenciaría cualquier soporte o comprensión de Microsoft para sus problemas de solución (esto no importa si la parte no compatible toca algo que cause problemas). El mero hecho de que tenga una parte sin soporte generalmente no implica soporte / responsabilidad.
Quizás las cosas hayan cambiado en esta era OpenSource. La simple respuesta oficial y la orientación de Microsoft me tranquilizarían y me ayudarían a comprender.

Agradecí tu respuesta. Saludos.

@dirkslab Creo que su gerente de cuenta de MSFT es la persona adecuada para preguntar sobre la política de soporte.

El equipo de CoreFX pregunta sobre casos de uso

Aparte de los beneficios obvios de que yaml está a nuestro alrededor en CI / CD hoy en día y la cantidad de sistemas de configuración, el beneficio adicional de ConvertTo-Yaml es representar HashTable nasted en formato legible por humanos , a diferencia de ConvertTo-Json que tenemos que usar ahora lo que hace que la salida no sea muy legible.

Mientras tanto, uso Write-HashTable , pero sería genial tener OTB.

Odio el yaml, realmente lo odio. Sin embargo, hay un par de facetas que vale la pena considerar por el equipo de MS:

1. Se ha convertido en el lenguaje de facto de CI: docker-compose.yaml, ansible, kuber, k8s, github, circle, azure, ... Y parece salir de CI a los proyectos que lo usan.

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

Tener este barco con PowerShell sería transformador en la evangelización a los grupos de CI.
"Si cambiamos a ms powershell podemos automáticamente" -> "¿Dime más?"
vs
"Si cambiamos a ms powershell y descargamos algunos scripts de la galería" -> "no"

1. Realmente, esto es por casualidad, pero yaml es un superconjunto de json, de modo que json es una forma abreviada de yaml, un analizador yaml eficiente es un analizador json eficiente,

¿Se puede reconsiderar esto para 7.1? También tengo problemas con el uso de un módulo que no es de confianza y algo por lo que DevsOpsy realmente debería ser nativo de PowerShell.

En mi humilde opinión, YAML es tan popular como JSON y CSV, y no tener convertidores de bandeja de entrada para YAML en PowerShell es algo triste. Tener convertidores YAML en la bandeja de entrada también asegurará que su comportamiento esté a la par con los convertidores JSON, lo que no es el caso de los módulos comunitarios.

No me malinterpretes, aprecio que la gente cree módulos para la comunidad, pero en el estado actual del mundo, la conversión YAML es una apuesta importante; no esperamos que la gente descargue módulos de terceros para la conversión JSON.