Powershell: Convertir à partir de Yaml, Convertir à Yaml

Nous avons eu une discussion similaire sur l' aspect DSC ,
nous permettant de modifier les fichiers de configuration basés sur json, nous voulions avoir des options pour modifier les fichiers basés sur xml, les fichiers basés sur YAML, les fichiers basés sur INI prenant en charge les swaps RegEx à partir des cmdlets de manipulation de texte.

Le manque de support existant dans PS signifie que nous devons travailler dur pour obtenir une telle capacité.
Il a été suspendu en attendant la contribution de la communauté, mais s'il était intégré à PS, cela faciliterait également la tâche de la partie DSC.

Quand vous dites nativement, voulez-vous dire comme XML ou JSON?

La réflexion actuelle est que YAML ne doit

Si YAML était intégré dans PowerShell comme XML, ce serait impossible (pensez à [xml] " b ")

Si nous suivions la route JSON, vous auriez des applets de commande pour fonctionner avec YAML - donc pas vraiment intégrées à PowerShell, mais vous auriez toujours les inconvénients de devoir mettre à jour PowerShell pour obtenir les mises à jour YAML.

@lzybkr Je sais que nous avons dit que nous ne voulions pas apporter une nouvelle bibliothèque, mais je pense que c'est quelque chose que nous devrons peut-être réévaluer. Idéalement, nous devrions également expédier le module sur la galerie, mais je pense qu'une TONNE de scénarios modernes nécessite YAML maintenant.

Peut-être pas dans la version 6.0, mais nous devrions en parler.

@ArieHein - J'ai quelques fonctions simples qui enregistrent et récupèrent un tableau de hachage dans le registre. Ne manipulez que REG_SZ - mais pour un simple jeu de paramètres, c'est suffisant - faites-moi savoir si vous voulez une copie.

Je me suis trompé quand j'ai dit "natif" - je voulais principalement dire "intégré" - cela ne me dérangerait pas s'ils étaient livrés avec des modules de script qui pourraient être mis à jour.

Notre première discussion # 2109

@iSazonov - ah oui je vois!

J'ai remarqué la référence à la prise en charge AWS de YAML sur le thread - j'ai converti certains modèles et j'ai trouvé cela utile: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov merci pour le pointeur, je n'ai pas pu le trouver pour une raison quelconque. Souvenez-vous bien, cependant.

En relisant ce fil d'origine, je pense que nous devrions certainement implémenter les applets de commande à un moment donné dans le futur et les expédier dans la Galerie. Sur la base de leur qualité et de l'utilité perçue par les gens (ainsi que du travail de refactorisation que nous espérons faire après la version 6.0.0), nous pouvons faire l'appel en boîte ou en galerie uniquement.

Nous avons Yaml dans https://github.com/PowerShell/platyPS

ouais, ce serait génial d'avoir fini par utiliser https://github.com/awslabs/aws-cfn-template-flip pour convertir

@MattTunny Bienvenue à contribuer! :-)

Il y a une voix d'utilisateur Windows Server ouverte pour voter pour cela :-)

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

Cela devrait certainement faire partie de la bibliothèque PS 6.1 native. Tellement de choses ces jours-ci sont dans YAML.

Il y a maintenant des modules psyaml et powershell-yaml sur la PSGallery, mais les deux ne sont même pas capables d'aller-retour d'un fichier YAML à partir d'une définition de build VSTS. Cela ne me dérange pas si le module est intégré dans PowerShell ou est un module de la PSGallery.

Je me demande si le problème principal ici est la façon maladroite de déployer les modules. Aujourd'hui, vous devez trouver, faire confiance et installer un module avant de pouvoir l'utiliser. Comparez cela avec la manière (apparemment) astucieuse dont Javascript fait var m = require('mymodule') . Peut-être que nous devrions avoir un moyen de faire ce que fait DSC, mais pour PowerShell natif. Dans DSC, lorsqu'un module est référencé dans une configuration, il est automatiquement téléchargé et installé sur le nœud cible sans effort manuel. La mise à disposition de modules critiques mais non essentiels de cette façon devrait éliminer les arguments «cela devrait faire partie du noyau». Et pour les nœuds qui sont déconnectés du réseau, nous pourrions avoir un outil qui regroupait les dépendances dans un script dans une archive qui serait ensuite déployée sur la cible. C'est ainsi que fonctionne l'extension de ressource Azure DSC - il existe un outil qui analyse un script pour déterminer les modules requis, puis crée un fichier zip contenant tout ce qui est nécessaire et le publie dans un objet blob. L'extension de ressource Azure extrait ensuite cet objet blob, installe les modules et exécute le script.

Pour quelque chose d'aussi important, je ne veux vraiment jamais dépendre d'une bibliothèque tierce à moins d'avoir un moyen de la vendre. Il est bien trop facile pour les développeurs tiers de potentiellement casser des écosystèmes entiers (voir https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

Mis à part les problèmes plus généraux, il n'existe actuellement aucun bon module YAML pour PowerShell, comme l' a souligné

@bgshacklett D'après ce que j'ai entendu des gars de Puppet, il n'y a tout simplement pas de bons analyseurs YAML :-)

L'analyseur platyPS est-il assez bon?

@vors Existe-t-il un moyen simple de réutiliser l'analyseur platyPS YAML dans le référentiel PowerShell Core?

Je préfère l'idée d'un module officiel distinct dans PowerShell Gallery comme le dit @lzybkr car il serait possible de l'utiliser dans les anciennes versions PowerShell et il pourrait avoir ses propres versions. Ce serait comme le module sqlserver . @BrucePay s'il s'agissait d'une page dans PowerShell Gallery avec des modules propres à Microsoft, ce serait plus facile à trouver et tout le monde saurait qu'ils peuvent leur faire confiance.

Mais je comprendrais s'il était sauvegardé dans Powershell en tant que XML et JSON.

L'important est qu'il existe des fonctions officielles ConvertFrom-YAML et ConvertFrom-YAML car YAML est un format largement utilisé pour les fichiers de configuration et il ne devrait pas être un module tiers, comme le souligne @bgshacklett .

J'ai fait une entrée de blog testant et comparant les deux modules que j'ai trouvés pour fonctionner avec les fichiers YAML: PSYaml et powershell-yaml .

Ils ont des comportements différents car ils utilisent en interne des objets différents:

| module | mappages | séquences |
| --------- |: -------------- | ----------- |
| PSYaml | OrderedDictionary | Array |
| powershell-yaml | Hastable | Liste |

Je pense que nous avons besoin d' une norme ConvertFrom-YAML et ConvertFrom-YAML .

En fait, ConvertFrom-Yaml in powershell-yaml utilise OrderedDictionary lors de la conversion avec le paramètre -ordered .
J'utilise ce module avec succès depuis un certain temps (dans mon module Datum pour les données de configuration DSC et avec les yamls de cuisine), mais je n'ai pas de définition de construction vsts à tester.

Gardez à l'esprit que la bonne façon de l'appeler est: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (les gens manquent souvent le -Raw ).

Je me demande pourquoi nous aurions besoin d'un module Microsoft _official_, mettant encore plus de frais généraux sur MSFT et réinventant la roue ... Peut-être essayer de contribuer à un module existant en premier, ajouter des tests pour éviter la régression, ouvrir des problèmes pour s'assurer que le propriétaire connaît le problèmes est une meilleure approche ...
Vous savez ce qui se passe lorsque vous essayez de créer un standard parmi les 99 implémentations existantes ...

Et oui ce serait mieux en dehors du langage, je suis d'accord que la gestion des dépendances pourrait être meilleure, regrouper tout dans PS n'est cependant pas une solution.
Le problème général de npm est également un échec du processus. Fork et republier l'ont corrigé en un rien de temps, la création d'applications à partir de la dernière version d'Internet était la raison pour laquelle il a cassé tant d'applications en direct.

Je suis d'accord avec @gaelcolas Je pense que c'est mieux si tout le monde travaille avec les propriétaires d'un module communautaire existant pour augmenter et garantir la qualité.

J'ajouterai simplement que les tests pour un tel projet devraient inclure le travail avec un grand nombre de fichiers YAML du monde réel pour des choses comme AppVeyor, Travis CI, VSTS, AWS CloudFormation, etc. Pour ma propre expérience avec la déserilisation YAML, j'ai eu peu de succès avec une solution fonctionnant universellement et ont finalement dû réinventer la roue à plusieurs reprises. En ce sens, je suis d'accord avec @BrucePay "il n'y a tout simplement pas de bons analyseurs YAML".

Nous parlons de ce module platyPS car il est déjà activement utilisé dans l'environnement d'aide PowerShell. Je suppose que personne de MSFT ne peut dire à quel point ce module est bon en raison du code de conduite. Ils peuvent soit le rejeter en silence, soit l'améliorer.
Et bien que nous en parlions il y a longtemps, je ne vois pas comment nous pourrions utiliser les composants de ce module ici d'une manière simple.
Peut-être que @adityapatwardhan et @ SteveL-MSFT ouvriront leurs plans et leur chronologie d'autant plus que le nouveau Help RFC est déjà au stade de l'expérimentation.

Mon opinion personnelle est que je préférerais voir plus de modules communautaires réussir et devenir de facto standard plutôt que d'exiger des modules "officiels" de Msft.

@iSazonov C'est une chose d'avoir une solution qui fonctionne pour sérialiser / désérialiser un schéma bien défini. C'est une autre chose d'avoir une solution qui fonctionne en général avec tous les schémas conformes YAML.

Je comprends le désir de MSFT de réutiliser les projets communautaires pour réduire les coûts. Mais la situation est, en fait, que MSFT ne peut pas utiliser autant de projets communautaires:

• beaucoup ont un mauvais code, n'ont aucune confiance
• de nombreux projets sont une seule personne

MSFT a publié les spécifications Powershell il y a plus de 10 ans, mais personne ne les a portées jusqu'à ce que MSFT le fasse.
Le projet OpenSSL existe depuis de nombreuses années mais personne ne l'a porté sur Windows alors que MSFT ne l'a pas fait.
MSFT a révélé plusieurs milliers d'interfaces API, mais combien d'entre elles ont été portées sous Unix?
La chose intéressante à propos de pourquoi l'entreprise a lancé son projet .Net Core plutôt que de réutiliser Mono?
PowerShell est déjà un an et demi est un projet open source, mais je vois que dans ce référentiel une seule personne de la communauté apporte une contribution systématique dans le code @markekraus et une seule personne fait une analyse systématique @ mklement0.
Je ne pense pas que si nous divisons le projet en plusieurs parties, nous aurons plus de contributions.
Je ne pense pas que la situation changera demain. Je ne compterais pas dessus.

@markekraus j'espère beaucoup sur http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov fait des
Cependant, il ne faut pas supposer qu'un bon module YAML évoluera de lui-même au cours des prochaines années. La réalité est que la plupart des modules sont publiés par des auteurs qui ont résolu un problème particulier et ont fait la bonne action de publier leur code de base générique. C'est ainsi que nous nous sommes retrouvés avec 2 modules qui visent à résoudre le même problème. Dans l'idéal, il faudrait les fusionner pour concentrer les efforts, sinon ils se sépareront davantage à l'avenir ou deviendront simplement obsolètes et bientôt il y aura plus de modules publiés par d'autres personnes.
Le problème sous-jacent d'avoir un analyseur approprié indique qu'un travail de base (et substantiel en termes d'effort) est nécessaire et nécessaire pour avoir un bon module YAML.
Je ne suis pas un expert YAML, mais est-ce juste un problème de spécification de langage lâche lui-même ou d'interprétation spécifique par divers systèmes comme VSTS ou AppVeyor ou est-ce seulement le manque d'un bon analyseur?
J'ai trouvé frustrant d'écrire YAML dans VSCode et seulement lors de son exécution dans VSTS pour obtenir une erreur que l'analyseur VSTS ne l'aime pas ...

Pour moi, cette conversation est un exemple typique du problème de «curation / architecture de code» de l'open source.

L'open source fournit de bonnes idées d'amorçage et des bases de code - mais si un œil sérieux sur l'architecture n'est pas donné lors de son adoption comme solution la plus générale - alors ce sont 10 ans de corrections de bogues pour des éléments qui auraient pu être pris en charge dans une revue de conception décente .

Dans les vrais cas de @bergmeister "succès matures", c'est souvent un mainteneur actif qui a pris la mission de généraliser la base de code. Mais cela ne peut être garanti.

Je pense que certains d'entre nous disent: "Le support YAML est comme le support pour l'écriture de fichiers - c'est le cœur - il devrait être structuré de la même manière => avec l'intention d'être la référence pour cette fonctionnalité"

La combinaison de 1) l'attribut semi-architectural de l'open source avec la nature 2) de base de YAML qui semblent inciter beaucoup d'entre nous à adopter une approche hautement architecturée que nous savons que les développeurs Microsoft PowerShell appliquent à leur travail. Ce n'est pas nécessairement une dérive de toutes les autres choses intéressantes que l'open source peut effectivement nous aider.

Des points très valables sur la maturité du logiciel. Je n'ai pas regardé attentivement les deux modules listés ici, ni yamldotnet pour me faire une opinion. Quelque chose que nous pouvons examiner lorsque nous commençons à planifier la version 6.2.0

Ne vous méprenez pas, j'apprécie l'expérience et l'approche systématique de l'équipe PowerShell et des développeurs MSFT, je pense simplement que c'est mal pour eux d'essayer de combler toutes les lacunes avec un module de leur propre MSFT estampillé ... pas de mise à l'échelle (et nous avons déjà vu le problème avec les ressources DSC).
Augmenter la dépendance aux modules fournis par MSFT est fragile et ne contribue pas à la croissance de la communauté, ni à la diversité de l'écosystème.
Je suis favorable à ce que MSFT contribue à des projets open source pour partager leur expérience et aider à améliorer les pratiques et la qualité, sans créer de dépendance à leur égard (car vous savez, les écureuils ...!).
Le _MSFT en tant que fournisseur unique de choses approuvées_ est un ancien modèle sur lequel ils ont déjà du mal à éduquer, et il n'aide pas la communauté à encourager cette approche (c'est-à-dire que je vais attendre ou gémir chez Microsoft pour ne pas avoir résolu le problème que j'ai_ type d'attitude dans l'écosystème OSS).

Je suis d'accord que le support YAML est essentiel, au lieu que l'équipe PS réécrive à partir de zéro, pourquoi ne pas aider les mainteneurs de projets existants à s'améliorer, et leur donner l'occasion de fusionner des projets et d'entendre ce qu'il faudrait. Un peu comme un apprentissage / mentorat de l'équipe PS sur les modules de fonctionnalités de base.
La simple réécriture d'un nouveau module ressemble à la réaction d'un ingénieur pour résoudre un problème qui n'est pas un problème d'ingénierie. La réécriture d'un module YAML est une tâche d'ingénierie facile pour l'équipe PS, mais ne contribuerait pas à résoudre le problème de maturité de la communauté, ni ne donnerait la bonne incitation.
Si Yaml est l'élément stratégique pour s'attaquer à cela, c'est l'appel de MSFT :)

@bergmeister

Je vais commencer par ne pas être un expert YAML. Il m'est arrivé de faire des recherches à ce sujet lorsque je voulais intégrer des configurations AppVeyor comme yaml dans mon propre pipeline franken. J'ai regardé comment une douzaine de projets C # consommaient YAML. Étant donné que les projets PowerShell utilisent YamlDotNet, je ne peux que supposer que ce n'est pas plus facile. Bien que j'aie au moins joué avec PSYaml et powershell-yaml et que j'aie regardé de moins près quelques projets PowerShell qui les utilisent.

Je ne suis pas un expert YAML, mais est-ce juste un problème de spécification de langage lâche lui-même ou d'interprétation spécifique par divers systèmes comme VSTS ou AppVeyor ou est-ce seulement le manque d'un bon analyseur?

Je soupçonne que c'est la nature de YAML d'être lisible par les humains au détriment possible d'être plus facilement lisible par des machines. Ce paradigme de la lisibilité avant tout s'étend à la façon dont les auteurs YAML écrivent leurs fichiers YAML. Bien que le YAML résultant soit conforme à la spécification YAML, il est analysé de manière à être inutilisable dans le code sans utiliser l'objet désérialisé comme intermédiaire vers un objet réellement utile.

C'est-à-dire que 90% du temps, la désérialisation de YAML vers un objet n'est pas le problème, mais la conception / l'architecture des données l'est. L'autre 10% du temps _est_ des problèmes d'analyse pour lesquels je ne peux que "YAML est difficile à analyser, mec". Cependant, les objets désérialisés ne sont souvent que légèrement plus utiles que l'expression de ce que vous recherchez ...

À titre d'exemple, les chaînes sécurisées dans AppVeyor.yml

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

powershell-yaml et YamlDotNet le convertissent en objet, mais bonne chance de l'utiliser sans un tas de logique. Une fois que vous avez cette logique, c'est bien pour ce schéma, mais qu'en est-il d'un autre?

Certains de ces mêmes problèmes de conception de données affectent JSON, mais il est (selon mon expérience et mon avis) beaucoup plus facile de créer des modèles capables de contourner ces lacunes en raison de la nature plus rigide de JSON. Essayer de créer des modèles pour l'un des désérialiseurs YAML mentionnés dans ce fil est un cauchemar si et où cela est possible.

Certes, les modèles ne sont pas une fonctionnalité actuellement disponible dans les applets de commande JSON, bien que j'aimerais vraiment l'ajouter. Si j'avais mon mot à dire dans le module / applets de commande YAML "officiels", je le placerais comme une fonctionnalité "indispensable". C'est une occasion manquée notamment avec l'ajout de classes PowerShell dans la v5.

OMI, il ne suffit pas d'obtenir des chaînes YAML dans un objet. Cela semble facile (au moins 90% du temps). L'astuce consiste à obtenir des chaînes YAML dans des objets _useful_. Cela nécessite une certaine flexibilité de la solution. Mais cette flexibilité doit aussi être quelque peu accessible et ne pas nécessiter @IISResetMe et @lzybkr pour vous donner des conseils de sérialisation ....

À cet effet, je n'ai rien vu qui fonctionne sur une portée générale. Les projets adoptent les solutions disponibles, puis utilisent leurs résultats comme intermédiaires pour des objets réellement utiles (conduisant à une réinvention de la roue qui devrait probablement être cuite en amont). Ou bien, les projets compromettent la lisibilité YAML pour faciliter l'analyse de YAML vers les objets.

@gaelcolas

Je suis d'accord que le support YAML est essentiel, au lieu de la réécriture de l'équipe PS à partir de zéro, pourquoi ne pas aider les mainteneurs de projets existants à s'améliorer, et leur donner l'occasion de fusionner des projets et d'entendre ce qu'il faudrait

Demandez-vous pourquoi MSFT a lancé le projet .Net Core au lieu de continuer Mono plusieurs années plus tard.

MSFT est aussi une communauté. Et comme toute communauté a les mêmes problèmes d'interaction avec les autres communautés.

Pour le contexte, je n'implique aucun travail à partir de zéro - le code pourrait être adopté - mais devrait ensuite être examiné du point de vue de l'architecture de développement de systèmes avant d'être amélioré. Il pourrait même être open source après cet examen et cette réédition.

Mon point est d'avoir un examen architectural et une correction importants par une équipe qui comprend parfaitement les nuances du code de base qui sera exploité pratiquement partout.

Un autre modèle qui mérite toujours d'être considéré est celui d'acquérir / de contracter / de seconde. Sur cette base, un effort est fait pour parvenir à des conditions commerciales avec un ou plusieurs membres de la communauté / entreprises afin de recruter leurs services pour un cycle de développement dirigé / facilité par MSFT pour réorganiser et (d'une certaine manière) intégrer / connecter le (s) produit (s) . Cela a été fait avec succès avec Xamarin, qui a lancé le projet à la Net Foundation, l'a autorisé sous le MIT et a recruté / engagé / impliqué des ressources clés telles que Miguel de Icaza et Nat Friedman via Xamarin. Certains se plaignent qu'il s'agit d'une trahison open source. Mais cela crée des incitations positives pour les gens et les petites entreprises à concevoir et développer des projets qui pourraient plus tard être adaptés à une adoption généralisée et à une intégration dans au moins un écosystème majeur. Il est certainement préférable de passer directement à une refonte interne vierge qui copie l'ensemble du concept, des fonctionnalités et de nombreuses idées, mais abandonne les créateurs et (ostensiblement) le code.

@iSazonov désolé pour une réponse tardive, non l'analyseur platyPS yaml n'est pas bon: il ne prend en charge que les paires clé-valeur. Nous utilisons également YamlDotNet pour générer yaml.

En ce qui concerne le sentiment de garder cela en dehors de l'ensemble des fonctionnalités de base: il existe une différence très significative dans la façon dont PowerShell gère les dépendances par rapport à, par exemple, Ruby, Python ou Node.js.

Chacun de ces langages dispose d'outils de gestion des dépendances (bundler, pip, npm / yarn) qui facilitent la gestion des dépendances externes et, plus important encore, reproductibles. Avoir quelque chose comme un Gemfile/Gemfile.lock ou package.json/package-lock.json [,yarn.lock] qui facilite l'installation de tous les packages requis et garantit que vous restez à un niveau de patch très spécifique est une distinction très significative qui est, à mon avis, ce qui rend les bibliothèques tierces pour quelque chose d'aussi fondamental faisable.

Il y a peut-être quelque chose qui pourrait être fait avec Nuget pour résoudre ce problème, mais je n'ai jamais vu d'articles décrivant les stratégies / modèles de gestion des dépendances pour PowerShell. Avoir la galerie est génial, mais si vous devez installer manuellement tous les packages requis, cela devient impossible pour un déploiement important.

Éditer:
Il semble donc que ce que je recherche _peut_ être déjà disponible: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. Je vais tester cela dès que j'aurai un moment. Si cela fonctionne, je devrai reconsidérer ma position sur la question de savoir si cela devrait être un élément essentiel ou non. J'ai encore du mal à le concilier avec le fait que JSON est une fonctionnalité de base, mais je suppose que cela pourrait être considéré comme un "plus petit dénominateur commun".

@bgshacklett fait un très bon point.

@ chuanjiao10 - veuillez arrêter les commentaires perturbateurs sur de nombreux problèmes de ce référentiel, la solution correcte ne serait Microsoft.PowerShell.Utility et de les expédier en tant que module séparé hébergé dans PowerShellGallery

Quand vous dites nativement, voulez-vous dire comme XML ou JSON?

La réflexion actuelle est que YAML ne doit

Si YAML était intégré dans PowerShell comme XML, ce serait impossible (pensez à [xml] "b")

Si nous suivions la route JSON, vous auriez des applets de commande pour fonctionner avec YAML - donc pas vraiment intégrées à PowerShell, mais vous auriez toujours les inconvénients de devoir mettre à jour PowerShell pour obtenir les mises à jour YAML.

Personnellement, même si cela semble être la «bonne» chose à faire dans la boîte de réception, je suggérerai que ce n'est pas la bonne chose à faire

@lzybkr Je sais que nous avons dit que nous ne voulions pas apporter une nouvelle bibliothèque, mais je pense que c'est quelque chose que nous devrons peut-être réévaluer. Idéalement, nous devrions _aussi_ expédier le module sur la Galerie, mais je pense qu'une TONNE de scénarios modernes nécessitent YAML maintenant.

Peut-être pas dans la version 6.0, mais nous devrions en parler.

L'expédition d'un module externe est bien meilleure à mon avis, car elle peut être utilisée au niveau inférieur et l'OMI, c'est moins le travail de l'équipe PowerShell de le faire et plus la communauté doit le conduire avec l' aide de l'équipe PowerShell pour obtenir une qualité élevée lorsque cela est possible.

Encore une fois @ chuanjiao10, il avait été précédemment décidé de ne pas mettre les Cmdlets YAML dans PowerShell Core dans # 2109 et a été refusée à juste titre car elle devrait également l'être maintenant.

En ce qui concerne

l'unité fait la force. Un Américain qui a besoin d'une voiture, l'avez-vous vu aller chez Wal-Mart pour acheter une roue, aller sur Amazon pour acheter un moteur et se combiner (bricoler une voiture)?

Comparer une voiture à un logiciel est un peu une mauvaise analogie étant donné que les composants de la voiture proviennent de nombreux fournisseurs différents et sont ensuite emballés dans un produit utilisable, qui n'est pas différent des modules PowerShell développés par la communauté qui peuvent ensuite être mélangés et assortis. utilisé dans les scripts

Concernant ce point

La bibliothèque principale est intégrée, c'est très important, sinon je vois que convertfrom-json, convertto-json, etc., devrait également être placé dans PowerShellGallery.

J'ai préconisé cela pour autant de modules intégrés que possible selon # 1979 et j'aimerais que PowerShell Core soit aussi léger que possible, ce qui a commencé à être discuté plus en détail dans # 5681

et re

Ne discriminez pas YAML, ne flattez pas JSON.

Je ne discrimine pas Yaml ni ne flatteur Json car les deux ont leurs défauts mais les deux ont leurs utilisations et si j'avais pu influencer le fait de ne pas expédier les applets de commande Json dans PowerShell, j'aurais fait exactement la même chose que je fais ici.

Je pense qu'il peut être utile de recadrer un peu cette discussion. En particulier, les partisans de l'inclusion de YAML dans le langage de base seraient-ils prêts à répertorier des cas d'utilisation spécifiques et pourquoi un module de la galerie PowerShell est insuffisant pour répondre à ce cas d'utilisation? À ce stade, nous pouvons avoir une discussion axée sur les exigences et potentiellement trouver une solution viable pour le problème en question.

Mon cas d'utilisation principal concerne l'automatisation sans système d'exploitation du système d'exploitation et du déploiement d'applications. Dans au moins un cas, je souhaite lire un fichier YAML qui a appelé mon script pour comprendre les paramètres.
Souvent, dans ces cas, ayant une dépendance à un externe, sans SLA, le service est un énorme non-non. Cela peut affecter les activités de mise à l'échelle de la production.

C'est mon cas d'utilisation pour l'expédition dans l'empreinte la plus élémentaire du noyau PowerShell.

J'apprécie la discussion animée, essayons de la garder civile :)

@ PowerShell / PowerShell-Committee en avait déjà discuté. Nous convenons que le soutien de YAML est important compte tenu de sa prévalence aujourd'hui. Nous voulons également voir plus de modules que nous livrons actuellement dans PSCore6 déplacés afin que vous commenciez avec une installation minimale de PSCore6, puis ajoutez ce dont vous avez besoin (avec les métamodules, vous n'avez pas besoin d'ajouter plus de 10 modules, juste un pour DevOps , par exemple). Donc, en ce qui concerne YAML, la pensée actuelle est que cela devrait être un module séparé (je peux créer un dépôt sous l'organisation PowerShell si quelqu'un est prêt à commencer à prototyper cela, mon équipe n'a pas la bande passante pour le moment). L'utilisation de YamlDotNet (ou d'une autre bibliothèque tierce) est acceptable une fois qu'elle est évaluée du point de vue de la technologie, des licences et du support (similaire à la façon dont nous avons pris la dépendance à Json.Net). Cependant, la dernière fois que nous avons examiné YAML et YamlDotNet, le problème est que les implémentations de YAML varient considérablement et que cette bibliothèque n'a pas pris en charge tout ce qui existe (même les plus populaires).

Je dirai simplement que le support YAML est quelque chose que j'aimerais que l'équipe examine dans la version 6.2.

@ SteveL-MSFT Pourriez-vous s'il vous plaît commenter en fonction du problème et https://github.com/dotnet/corefx/issues/34578? Pourrions-nous utiliser YamlDotNet ou nous avons besoin d'une API plus fiable de CoreFX?

in.my opinion est que laissez convertfrom-json, convertfrom-jaml avoir le même statut, soit déménager, soit intégré.

J'ai préconisé de déplacer les applets de commande JSON hors du projet. Beaucoup de changements aimeraient apporter des modifications assez importantes, mais ils ne peuvent pas être apportés car les applets de commande sont liées à PowerShell. Les déplacer hors du projet nous permet d'apporter les changements majeurs dans une nouvelle version majeure du module cmdlets, et d'avoir PowerShell livré avec une version plus ancienne offrant une compatibilité ascendante mais permettant aux utilisateurs de mettre à jour s'ils le souhaitent ... Cependant, c'est un énorme problème pour inclure des modules externes comme celui-ci, l'OMI.

Je préférerais que nous apprenions de nos erreurs avec JSON et Pester plutôt que de traiter arbitrairement YAML de la même manière. Il ne devrait certainement pas faire partie des fonctionnalités de base de PowerShell, mais devrait certainement avoir une sorte de module officiellement pris en charge avec une propriété partagée entre la communauté et l'équipe PS.

J'aime cette idée. Déplacer les applets de commande JSON aiderait à résoudre les problèmes de flux de travail qui existent actuellement avec des dépendances matérielles sur des modules externes.

Mais yaml est important pour les administrateurs système, les développeurs de scripts. Ces utilisateurs ont besoin de commandes yaml.

Ils peuvent en avoir besoin, mais cela ne signifie pas qu'ils doivent être inclus directement dans PowerShell car un module externe est plus qu'acceptable et a un cycle de vie de support plus flexible que tout ce qui est inclus dans le référentiel principal.

Je dois dire que l'idée @ SteveL-MSFT d'un module DevOps Meta est vraiment la bonne façon pour cela à long terme car cela permet à différents ensembles d'utilisateurs d'obtenir un ensemble plus simple de packages qui sont beaucoup plus faciles à gérer en tant que dépendance externe plutôt que interne, ce qui pour moi a beaucoup de sens à l'avenir, bien qu'ils devraient être des méta-modules basés sur des piles technologiques, car si je suis sous Windows et n'utilise pas anisble, alors pourquoi aurais-je besoin de cmdlets yaml sur les fenêtres?

Bien qu'il existe un grand nombre d'utilisateurs dans le monde Linux utilisant yml comme mentionné par @ chuanjiao10, ce n'est pas le cas dans le monde Windows, qui, d'après ma compréhension de l'utilisation globale de PowerShell, reste en grande partie fidèle à PowerShell 5.1 car il est en boîte de réception sur leurs systèmes , et bien que le regroupement des applets de commande Yaml puisse aider les utilisateurs de Linux, cela me semble être un élément supplémentaire inutile pour les utilisateurs de Windows, mais traiter les deux ensembles d'utilisateurs de la même manière, il est tout à fait logique que cela finisse par être un module externe que les deux ensembles d'utilisateurs peut utiliser au besoin

Y a-t-il quelqu'un qui souhaite devenir propriétaire et accompagner ces applets de commande dans un projet séparé?

@iSazonov, il semble que corefx ne soit actuellement pas intéressé par le support YAML intégré. YamlDotNet semble être la bibliothèque la plus populaire, est sous licence MIT, activement maintenue, donc je commencerais par là. Un projet mené par la communauté serait incroyable et se produirait probablement plus tôt que si vous le laissiez à l'équipe PowerShell.

@ SteveL-MSFT semble que c'est pour une bonne raison - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255, ce qui, je pense, a réduit la confiance dans cette bibliothèque particulière.

il semble que corefx n'est actuellement pas intéressé par le support YAML intégré.

L'équipe CoreFX pose des questions sur les cas d'utilisation. Si le projet PowerShell dit que nous avons besoin de l'API, ils envisageront d'ajouter l'API.

Un projet mené par la communauté serait incroyable et se produirait probablement plus tôt que si vous le laissiez à l'équipe PowerShell.

Oh, je ne connais qu'un seul de ces projets - Pester. Et je ne crois pas au projet mené par la communauté yaml - pourquoi n'est-il pas apparu ces dernières années?
J'envisage de démarrer le projet mais cela m'a arrêté de ne jamais pouvoir atteindre le niveau de qualité, de conformité et de sécurité du code exigé par MSFT.
Je suppose que MSFT ne pourra jamais faire confiance et utiliser des projets sans audit de sécurité.
Je n'ai qu'une idée pour que ça marche. Les projets MSFT GitHub comme CoreFX et PowerShell sont «détenus par MSFT» et «pilotés par MSFT». Le nouveau type de projet pourrait être «détenu par MSFT», «piloté par la communauté» et «encadré par MSFT». Sous «mentoré», je veux dire la mise en œuvre d'un environnement où le projet sera fiable et de haute qualité.

Microsoft doit intégrer la prise en charge YAML dans la boîte pour PowerShell Core. Clair et simple.

@brettjacobson Oui, ce serait clair, simple et de haute qualité, mais l'équipe MSFT n'a pas autant de ressources. Êtes-vous prêt à contribuer? :-)

@brettjacobson - Microsoft n'a pas besoin de regrouper le support YAML. Cela peut être utile s'ils l'ont fait, mais ils ne sont pas tenus de le faire et il n'est pas du tout nécessaire de le faire.

Ceci est une demande de fonctionnalité pour quelque chose que beaucoup want et qui finirait par use mais n'est pas critique need et n'est donc pas susceptible d'être priorisé, ce qui est exactement ce que @ SteveL-MSFT essayait de comprendre quand il a dit ce qui suit

Je dirai simplement que le support YAML est quelque chose que j'aimerais que l'équipe examine dans la version 6.2.

Un projet mené par la communauté serait incroyable et se produirait probablement plus tôt que si vous le laissiez à l'équipe PowerShell.

L'équipe PowerShell n'est pas énorme et, par conséquent, en regardant de manière réaliste, le moyen le meilleur et le plus rapide de pouvoir obtenir une assistance pour YAML sera externe à l'ensemble de fonctionnalités de base de PowerShell, plutôt que d'être intégré au produit lui-même.

L'équipe CoreFX pose des questions sur les cas d'utilisation. Si le projet PowerShell dit que nous avons besoin de l'API, ils envisageront d'ajouter l'API.

@iSazonov À mon humble avis, il n'y aura jamais de support YAML intégré dans CoreFX, car il n'y a pas encore de support JSON complet.

Allez-vous donc attendre une "grande" bibliothèque tierce ou demander à James Newton-King de créer un Newtonsoft.Yaml ? :-)

@NextTurn Nous aurons une nouvelle implémentation Json (très rapide (plus rapide que Newton.Json) et très flexible) dans .Net Core 3.0.
L'équipe CoreFX ajoute toujours une nouvelle API s'il y a une grande demande de la communauté. S'il y a beaucoup de projets qui peuvent bénéficier de YAML, ils ajouteront. Actuellement, aucune demande de ce type ne l'est.

Qu'est-ce que je ne fais pas à chaque nouveau système pwsh ? Je fais Install-Module -Name powershell-yaml .

Mongo, Kubernetes, Istio, Ansible, nommez-le - j'utilise. Tous ceux-ci sont YAML et j'ai des modèles et des transformations YAML. pwsh semble bon pour DevOps et ils parlent YAML.

@ dzmitry-lahoda Le numéro # 5681 propose d'avoir une version `` riche '' de PowerShell livrée avec un ensemble de modules communs tels que par exemple Pester , etc. vainqueur clair entre les 2 modules yaml actuellement disponibles et ils se bousculent, il peut être difficile de choisir un favori.

Je ne vois qu'un seul YAML :(

Pester , ouais. Trop lourd pour intégrer le framework BDD dans la ligne principale, contrairement au lecteur YAML pour mes applications de conteneur pwsh.

Ce fil a-t-il été conclu. Quel est le module recommandé (ou suggéré) à utiliser par Microsoft?
Les pipelines DevOps utilisent yaml. Toute mon automatisation de déploiement est construite avec PowerShell. Il semble que yaml et powershell ne jouent pas bien. PowerShell est-il un mauvais choix pour l'automatisation Azure DevOps?
Besoin de réfléchir attentivement à mon utilisation / innovation future et apprécierait une certaine direction.
Merci d'avance!

@dirkslab Vous pouvez utiliser https://github.com/cloudbase/powershell-yaml

GitHub

cloudbase / powershell-yaml

PowerShell CmdLets pour la manipulation du format YAML. Contribuez au développement cloudbase / powershell-yaml en créant un compte sur GitHub.

Merci @iSazonov , c'est la solution que je teste en ce moment. Jusqu'à présent, la solution semble fonctionner correctement. Il n'y a probablement rien de mal à utiliser la solution.

Notez qu'en utilisant powershell-yaml, vous devez valider un module non approuvé. C'est la partie que je lutte pour comprendre. Microsoft recommande d'utiliser des pipelines yaml. Microsoft (ou au moins ce fil de discussion) suggère d'utiliser un module tiers afin que vous puissiez intégrer la configuration yaml avec PowerShell, mais n'en approuvez ni n'en recommandez aucun. Comment expliquez-vous cela logiquement à l'entreprise.
Jusqu'à présent, mon expérience a toujours été que si vous n'utilisez pas de solutions approuvées par Microsoft, cela mettrait en sourdine tout support ou compréhension de Microsoft pour vos problèmes de solution (cela n'a pas d'importance si la partie non prise en charge touche à quelque chose causant des problèmes). Le simple fait que vous ayez une pièce non prise en charge n'entraîne généralement aucun support / responsabilité.
Peut-être que les choses ont changé à l'ère de l'OpenSource. Une réponse officielle simple et des conseils de Microsoft me mettraient à l'aise et m'aideraient à comprendre.

J'ai apprécié votre réponse. Cordialement.

@dirkslab Je pense que votre gestionnaire de compte MSFT est la bonne personne pour poser des questions sur la politique de support.

L'équipe CoreFX pose des questions sur les cas d'utilisation

Outre les avantages évidents que yaml est tout autour de nous dans CI / CD aujourd'hui et le nombre de systèmes de configuration, l'avantage supplémentaire de ConvertTo-Yaml est de représenter Nasted HashTable dans un format lisible par l'homme , contrairement à ConvertTo-Json que nous devons utiliser maintenant ce qui rend la sortie peu lisible.

J'utilise Write-HashTable en attendant, mais ce serait génial d'avoir OTB.

Je déteste yaml, je déteste vraiment ça. Cependant, il y a quelques facettes à considérer par l'équipe MS:

1. C'est devenu le langage de facto de CI: docker-compose.yaml, ansible, kuber, k8s, github, circle, azur, ... Et il semble ramper hors de CI dans les projets qui l'utilisent.

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

Avoir ce vaisseau avec PowerShell serait transformateur en évangélisant aux groupes CI.
"Si nous passons à MS PowerShell, nous pouvons automatiquement" -> "Dites-m'en plus?"
contre
"Si nous passons à ms powershell et téléchargeons des scripts depuis la galerie" -> "non"

1. Vraiment, c'est by-the-by, mais yaml est un sur-ensemble de json, tel que json est une forme abrégée de yaml, un analyseur yaml efficace est un analyseur json efficace,

Cela peut-il être reconsidéré pour 7.1? J'ai également des problèmes avec l'utilisation d'un module non approuvé et quelque chose de ce genre, donc DevsOpsy devrait vraiment être natif de PowerShell.

À mon humble avis, YAML est aussi populaire que JSON et CSV, et ne pas avoir de convertisseurs de boîte de réception pour YAML dans PowerShell est un peu triste. Avoir des convertisseurs YAML de boîte de réception garantira également que leur comportement est à égalité avec les convertisseurs JSON, ce qui n'est pas le cas avec les modules de communauté.

Ne vous méprenez pas - j'apprécie que les gens créent des modules pour la communauté, mais dans l'état actuel du monde, la conversion YAML est un enjeu de table - nous ne nous attendons pas à ce que les gens téléchargent des modules tiers pour la conversion JSON.