Powershell: ConvertFrom-Yaml, ConvertTo-Yaml

Wir hatten eine ähnliche Diskussion unter DSC-Gesichtspunkten .
Damit wir JSON-basierte Konfigurationsdateien ändern können, wollten wir Optionen zum Ändern von XML-basierten Dateien, YAML-basierten Dateien und INI-basierten Dateien, die RegEx-Swaps unterstützen, aus Textmanipulations-Cmdlets heraus.

Mangelnde Unterstützung in PS bedeutet, dass wir hart arbeiten müssen, um solche Fähigkeiten zu erlangen.
Es wurde bis zum Community-Beitrag auf Eis gelegt, aber wenn es in PS eingebrannt würde, würde es auch für den DSC-Teil viel einfacher sein.

Wenn Sie nativ sagen, meinen Sie damit XML oder JSON?

Derzeit wird davon ausgegangen, dass YAML überhaupt nicht in PowerShell integriert werden sollte, sondern ein separates Modul, das Sie aktualisieren können, ohne eine neue Version von PowerShell zu erwerben.

Wenn YAML wie XML in PowerShell gebacken würde, wäre dies unmöglich (denken Sie an [xml] " b ").

Wenn wir den JSON-Weg gehen würden, hätten Sie Cmdlets, die mit YAML arbeiten könnten - also nicht wirklich in PowerShell integriert, aber Sie hätten immer noch die Nachteile, PowerShell aktualisieren zu müssen, um YAML-Updates zu erhalten.

@lzybkr Ich weiß, wir sagten, wir wollten keine neue Bibliothek auch das Modul auf der Galerie versenden, aber ich denke , eine TON von modernen Szenarien jetzt YAML erfordern.

Vielleicht nicht in 6.0 Zeitrahmen, aber wir sollten darüber reden.

@ArieHein - Ich habe einige einfache Funktionen, die ein Hash-Array speichern und in der Registrierung abrufen. Behandeln Sie nur REG_SZ - aber für einen einfachen Satz von Einstellungen ist es ausreichend - lassen Sie mich wissen, wenn Sie eine Kopie wünschen.

Ich habe falsch geschrieben, als ich "native" sagte - ich meinte hauptsächlich "eingebaut" - es würde mich nicht stören, wenn es sich um eingebaute Skriptmodule handelt, die aktualisiert werden könnten.

Unsere erste Diskussion # 2109

@iSazonov - ah ja ich

Ich habe den Verweis auf die AWS-Unterstützung von YAML im Thread bemerkt. Ich habe einige Vorlagen konvertiert und fand dies hilfreich: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov danke für den Zeiger, ich konnte ihn aus irgendeinem Grund nicht finden. Denken Sie jedoch gut daran.

Wenn wir diesen ursprünglichen Thread erneut lesen, sollten wir die Cmdlets auf jeden Fall irgendwann in der Zukunft implementieren und in der Galerie versenden. Aufgrund ihrer Qualität und der wahrgenommenen Nützlichkeit der Benutzer (zusammen mit einigen Refactoring-Arbeiten, die wir hoffentlich nach 6.0.0 durchführen werden) können wir den Anruf im Posteingang oder nur in der Galerie tätigen.

Wir haben Yaml unter https://github.com/PowerShell/platyPS

Ja, das wäre großartig, wenn ich https://github.com/awslabs/aws-cfn-template-flip zum Konvertieren verwenden würde

@MattTunny Willkommen, um beizutragen! :-)

Es gibt eine Windows Server-Benutzerstimme, die geöffnet ist, um dafür zu stimmen :-)

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

Dies sollte definitiv Teil der nativen PS 6.1-Bibliothek sein. So viele Dinge sind heutzutage in YAML.

Es gibt jetzt psyaml und powershell-yaml Module in der PSGallery, aber beide können nicht einmal eine YAML-Datei aus einer VSTS-Build-Definition umrunden. Es macht mir nichts aus, wenn das Modul in PowerShell gebacken ist oder ein Modul aus der PSGallery ist.

Ich frage mich, ob das Kernproblem hier die klobige Art und Weise ist, wie wir Module bereitstellen. Heute müssen Sie ein Modul finden, vertrauen und installieren, bevor Sie es verwenden können. Vergleichen Sie dies mit der (anscheinend) raffinierten Art und Weise, wie Javascript var m = require('mymodule') . Vielleicht sollten wir eine Möglichkeit haben, das zu tun, was DSC tut, außer für native PowerShell. Wenn in DSC auf ein Modul in einer Konfiguration verwiesen wird, wird es automatisch heruntergeladen und ohne manuellen Aufwand auf dem Zielknoten installiert. Wenn kritische, aber nicht zum Kern gehörende Module auf diese Weise verfügbar gemacht werden, sollten die Argumente "Es sollte Teil des Kerns sein" beseitigt werden. Und für Knoten, die vom Netz getrennt sind, könnten wir ein Tool haben, das die Abhängigkeiten in einem Skript in einem Archiv bündelt, das dann auf dem Ziel bereitgestellt wird. So funktioniert die Azure DSC-Ressourcenerweiterung: Es gibt ein Tool, das ein Skript scannt, um die erforderlichen Module zu ermitteln. Anschließend wird eine Zip-Datei mit allen erforderlichen Elementen erstellt und in einem Blob veröffentlicht. Die Azure-Ressourcenerweiterung zieht dann diesen Blob, installiert die Module und führt das Skript aus.

Für etwas, das so wichtig ist, möchte ich wirklich nie von einer Bibliothek eines Drittanbieters abhängig sein, es sei denn, ich habe eine Möglichkeit, sie zu verkaufen. Für Entwickler von Drittanbietern ist es viel zu einfach, möglicherweise ganze Ökosysteme zu zerstören (siehe https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

Abgesehen von größeren Problemen gibt es derzeit kein gutes YAML-Modul für PowerShell, wie @bergmeister hervorhob . Dies ist ein Muss für eine Sprache, die stark auf Automatisierung ausgerichtet ist. YAML-basierte Konfigurationsdateien sind derzeit sehr beliebt und es ist sehr schwer, sie zu vermeiden, selbst wenn Sie sich nicht mit den Meinungen eines Teams auseinandersetzen müssen, um dies zu tun. Stellen Sie sich die Gründe für die Einbeziehung von XML und JSON als Kernbestandteile der Sprache vor. Der Fall für YAML ist wirklich nicht so anders.

@bgshacklett Nach dem, was ich von den Puppet-Jungs gehört habe, gibt es einfach keine guten YAML-Parser :-)

Ist platyPS Parser gut genug?

@vors Gibt es eine einfache Möglichkeit, den platyPS YAML-Parser in PowerShell Core Repo wiederzuverwenden?

Ich bevorzuge die Idee eines separaten offiziellen Moduls in der PowerShell-Galerie, wie @lzybkr sagt, weil es möglich wäre, es in älteren Powershell-Versionen zu verwenden, und es könnte seine eigenen Releases haben. Das wäre wie das SQL Server- Modul. @BrucePay Wenn es sich um eine Seite in der PowerShell-Galerie mit Microsoft-eigenen Modulen handeln würde, wäre sie leichter zu finden und jeder würde wissen, dass er ihnen vertrauen kann.

Aber ich würde verstehen, wenn es als XML und JSON in Powershell gesichert würde.

Wichtig ist, dass es offizielle Funktionen ConvertFrom-YAML und ConvertFrom-YAML , da YAML ein weit verbreitetes Format für Konfigurationsdateien ist und kein Modul eines Drittanbieters sein sollte, wie @bgshacklett hervorhebt .

Ich habe einen Blogeintrag erstellt und die beiden Module verglichen, die ich für die Arbeit mit YAML-Dateien gefunden habe: PSYaml und Powershell-Yaml .

Sie haben unterschiedliche Verhaltensweisen, weil sie intern unterschiedliche Objekte verwenden:

| Modul | Zuordnungen | Sequenzen |
| --------- |: -------------- | ----------- |
| PSYaml | OrderedDictionary | Array |
| Powershell-Yaml | Hastable | Liste |

Ich denke, wir brauchen einen Standard ConvertFrom-YAML und ConvertFrom-YAML .

Tatsächlich verwendet ConvertFrom-Yaml in powershell-yaml OrderedDictionary wenn mit dem Parameter -ordered konvertiert wird.
Ich habe dieses Modul eine Weile erfolgreich verwendet (in meinem Datum-Modul für DSC-Konfigurationsdaten und mit Küchen-Yamls), habe aber keine vsts-Build-Definition zum Testen.

Denken Sie daran, dass der richtige Weg, es zu nennen, ist: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (Leute verpassen oft die -Raw ).

Ich frage mich, warum wir ein Microsoft-offizielles Modul benötigen, das MSFT noch mehr Aufwand bringt und das Rad neu erfindet ... Vielleicht versuchen Sie zuerst, einen Beitrag zu einem bestehenden zu leisten, fügen Sie Tests hinzu, um Regressionen zu vermeiden, und öffnen Sie Probleme, um sicherzustellen, dass der Eigentümer das kennt Probleme ist ein besserer Ansatz ...
Sie wissen, was passiert, wenn Sie versuchen, aus den 99 vorhandenen Implementierungen einen Standard zu erstellen ...

Und ja, es wäre besser außerhalb der Sprache. Ich stimme zu, dass das Abhängigkeitsmanagement besser sein könnte. Es ist jedoch keine Lösung, alles in PS zu bündeln.
Das allgemeine Problem mit npm ist ebenfalls ein Fehler im Prozess. Fork und Re-Publish haben es in kürzester Zeit behoben. Das Erstellen von Apps aus der neuesten Version des Internets war der Grund, warum so viele Live-Apps kaputt gingen.

Ich stimme @gaelcolas zu. Ich denke, dies ist besser,

Ich möchte nur hinzufügen, dass Tests für ein solches Projekt die Arbeit mit einer großen Anzahl von realen YAML-Dateien für Dinge wie AppVeyor, Travis CI, VSTS, AWS CloudFormation usw. umfassen sollten. Für meine eigenen Erfahrungen mit der YAML-Deserilisierung habe ich wenig Erfolg mit einer universell funktionierenden Lösung, die das Rad letztendlich mehrmals neu erfinden musste. In diesem Sinne stimme ich @BrucePay zu "es gibt einfach keine guten YAML-Parser".

Wir sprechen über dieses platyPS-Modul, da es bereits in der PowerShell-Hilfeumgebung aktiv verwendet wird. Ich denke, niemand von MSFT kann aufgrund des Verhaltenskodex sagen, wie gut dieses Modul ist. Sie können es entweder stillschweigend ablehnen oder verbessern.
Und obwohl wir schon vor langer Zeit darüber gesprochen haben, sehe ich nicht, wie wir die Komponenten dieses Moduls hier auf einfache Weise verwenden könnten.
Vielleicht öffnen @adityapatwardhan und @ SteveL-MSFT ihre Pläne und ihren Zeitplan, zumal sich der neue Help RFC bereits in der Experimentierphase befindet.

Meine persönliche Ansicht ist, dass ich lieber sehen würde, dass mehr Community-Module erfolgreich sind und de facto zum Standard werden, als "offizielle" Module von Msft zu verlangen.

@iSazonov Es ist eine Sache, eine Lösung zu haben, die zum Serialisieren / Deserialisieren eines genau definierten Schemas funktioniert. Es ist etwas ganz anderes, eine Lösung zu haben, die im Allgemeinen mit allen Schemas funktioniert, die mit YAML kompatibel sind.

Ich verstehe den Wunsch von MSFT, Community-Projekte wiederzuverwenden, um Kosten zu senken. Tatsächlich ist die Situation jedoch so, dass MSFT möglicherweise nicht so viele Community-Projekte nutzt:

• Viele haben schlechten Code, kein Vertrauen
• Viele Projekte sind eine Person

MSFT hat vor mehr als 10 Jahren Powershell-Spezifikationen veröffentlicht, aber bis MSFT hat dies noch niemand portiert.
Das OpenSSL-Projekt existiert seit vielen Jahren, aber niemand hat es auf Windows portiert, während MSFT dies nicht getan hat.
MSFT enthüllte viele tausend API-Schnittstellen, aber wie viele davon wurden auf Unix portiert?
Das Interessante daran, warum das Unternehmen sein Projekt .Net Core gestartet hat, anstatt Mono wiederzuverwenden?
PowerShell ist bereits anderthalb Jahre lang ein Open-Source-Projekt, aber ich sehe, dass in diesem Repository nur eine Person aus der Community einen systematischen Beitrag im Code @markekraus leistet und nur eine Person eine systematische Analyse @ mklement0 durchführt.
Ich denke nicht, dass wir mehr Beiträge erhalten, wenn wir das Projekt in Teile teilen.
Ich glaube nicht, dass sich die Situation morgen ändern wird. Ich würde nicht darauf zählen.

@markekraus Ich hoffe sehr auf http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov macht wichtige Punkte in
Man sollte jedoch nicht davon ausgehen, dass sich ein großartiges YAML-Modul in den nächsten Jahren von selbst entwickeln wird. Die Realität ist, dass die meisten Module von Autoren veröffentlicht werden, die ein bestimmtes Problem gelöst und die gute Tat getan haben, ihren generischen Basiscode zu veröffentlichen. So sind wir zu 2 Modulen gekommen, die das gleiche Problem lösen sollen. Im Idealfall müsste man sie zusammenführen, um die Bemühungen zu konzentrieren, sonst driften sie in Zukunft weiter auseinander oder werden einfach abgestanden, und bald werden weitere Module von anderen Personen veröffentlicht.
Das zugrunde liegende Problem, einen richtigen Parser zu haben, zeigt, dass grundlegende (und in Bezug auf den Aufwand erhebliche) Grundlagenarbeiten erforderlich und erforderlich sind, um ein gutes YAML-Modul zu haben.
Ich bin kein YAML-Experte, aber ist dies nur ein Problem der losen Sprachspezifikation selbst oder der spezifischen Interpretation durch verschiedene Systeme wie VSTS oder AppVeyor oder ist dies nur das Fehlen eines guten Parsers?
Ich fand es frustrierend, YAML in VSCode zu schreiben und nur, wenn es in VSTS ausgeführt wird, um einen Fehler zu erhalten, den der VSTS-Parser nicht mag ...

Für mich ist dieses Gespräch ein typisches Beispiel für das Open-Source-Problem "Code Curation / Architecture".

Open Source bietet gute Seeding-Ideen und Code-Grundlagen - aber wenn es bei der Annahme als allgemeinste Lösung nicht ernsthaft um die Architektur geht, werden 10 Jahre lang Fehlerbehebungen für Elemente vorgenommen, die in einer anständigen Entwurfsprüfung hätten behoben werden können .

In den wahren Fällen von @bergmeister "reifen Erfolgen" ist es oft ein aktiver Betreuer, der die Aufgabe übernommen hat, die Codebasis zu verallgemeinern. Das kann aber nicht garantiert werden.

Ich denke, einige von uns sagen: "YAML-Unterstützung ist wie Unterstützung für das Schreiben von Dateien - es ist der Kern - es sollte auf die gleiche Weise aufgebaut werden => mit der Absicht, der Goldstandard für diese Funktionalität zu sein."

Die Kombination von 1) dem semi-architektonischen Attribut von Open Source mit dem 2) Kerncharakter von YAML, die viele von uns nach dem stark architektonischen Ansatz zu drängen scheinen, von dem wir wissen, dass die Microsoft PowerShell-Entwickler ihn auf ihre Arbeit anwenden. Es ist nicht unbedingt ein Abdriften von all den anderen coolen Dingen, bei denen Open Source uns tatsächlich helfen kann.

Sehr gültige Punkte zur Software-Reife. Ich habe mir die beiden hier aufgeführten Module und yamldotnet nicht genau angesehen, um eine Meinung zu bilden. Etwas, das wir uns ansehen können, wenn wir mit der Planung für 6.2.0 beginnen

Versteh mich nicht falsch, ich schätze die Erfahrung und den systematischen Ansatz des PowerShell-Teams und der MSFT-Entwickler. Ich denke nur, dass es falsch ist, wenn sie versuchen, alle Lücken mit einem Modul ihrer eigenen gestempelten MSFT zu füllen nicht skalierbar (und wir haben das Problem mit DSC-Ressourcen bereits gesehen).
Die zunehmende Abhängigkeit von MSFT-bereitgestellten Modulen ist fragil und trägt weder zum Wachstum der Community noch zur Vielfalt des Ökosystems bei.
Ich bin dafür, dass MSFT zu Open-Source-Projekten beiträgt, um ihre Erfahrungen auszutauschen und zur Verbesserung von Praktiken und Qualität beizutragen, ohne eine Abhängigkeit von ihnen zu schaffen (weil Sie wissen, Eichhörnchen ...!).
Die MSFT als einzigartiger Anbieter genehmigter Dinge ist ein altes Modell, über das sie bereits Schwierigkeiten haben, sich zu informieren, und sie hilft der Community nicht, diesen Ansatz zu fördern (dh ich werde bei Microsoft warten oder stöhnen, wenn ich das Problem, das ich habe, nicht gelöst habe) Art der Einstellung im OSS-Ökosystem).

Ich bin damit einverstanden, dass die YAML-Unterstützung von zentraler Bedeutung ist, anstatt dass das PS-Team von Grund auf neu schreibt. Warum nicht den bestehenden Projektbetreuern helfen, sich zu verbessern, und ihnen die Möglichkeit geben, Projekte zusammenzuführen und von ihnen zu hören, was erforderlich ist? Ein bisschen wie eine Ausbildung / Betreuung durch das PS-Team in Kernfunktionsmodulen.
Nur ein neues Modul neu zu schreiben, klingt wie die Reaktion eines Ingenieurs, ein Problem zu lösen, das kein technisches Problem ist. Das Umschreiben eines YAML-Moduls ist eine einfache Engineering-Aufgabe für das PS-Team, würde jedoch weder das Problem der Community-Reife beheben noch den richtigen Anreiz bieten.
Ob Yaml der strategische Punkt ist, um dies anzugehen, ist jedoch die Forderung von MSFT :)

@bergmeister

Ich werde dies vorwegnehmen, indem ich kein YAML-Experte bin. Ich habe diesbezüglich einige Nachforschungen angestellt, als ich AppVeyor-ähnliche Yaml-Konfigurationen in meine eigene Franken-Pipeline backen wollte. Ich habe mir angesehen, wie ein Dutzend C # -Projekte YAML verbrauchen. Da die PowerShell-Projekte YamlDotNet verwenden, kann ich nur davon ausgehen, dass dies nicht einfacher ist. Obwohl ich zumindest mit PSYaml und Powershell-Yaml herumgespielt habe und mir einige PowerShell-Projekte, die sie verwenden, weniger genau angesehen habe.

Ich bin kein YAML-Experte, aber ist dies nur ein Problem der losen Sprachspezifikation selbst oder der spezifischen Interpretation durch verschiedene Systeme wie VSTS oder AppVeyor oder ist dies nur das Fehlen eines guten Parsers?

Ich vermute, es liegt in der Natur von YAML, von Menschen auf Kosten einer besseren Lesbarkeit durch Maschinen lesbar zu sein. Dieses Paradigma der Lesbarkeit erstreckt sich auf die Art und Weise, wie YAML-Autoren ihre YAML-Dateien schreiben. Obwohl die resultierende YAML unter der YAML-Spezifikation kompatibel ist, wird sie so analysiert, dass sie im Code unbrauchbar ist, ohne das deserialisierte Objekt als Vermittler für ein tatsächlich nützliches Objekt zu verwenden.

Das heißt, dass in 90% der Fälle die Deserialisierung von YAML zu einem Objekt nicht das Problem ist, sondern das Datendesign / die Datenarchitektur. Die anderen 10% der Zeit sind Probleme beim Parsen, für die ich nur "YAML ist schwer zu analysieren, Mann" verwenden kann. Die deserialisierten Objekte sind jedoch oft nur geringfügig nützlicher als die Regexierung dessen, wonach Sie suchen.

Als Beispiel die sicheren Zeichenfolgen in AppVeyor.yml

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

powershell-yaml und YamlDotNet konvertieren dies zwar in ein Objekt, aber viel Glück beim Verwenden ohne viel Logik. Sobald Sie diese Logik haben, gut für dieses Schema, aber was ist mit einem anderen?

Einige dieser Probleme beim Entwurf von Daten plagen JSON, aber es ist (meiner Erfahrung und Meinung nach) viel einfacher, Modelle zu erstellen, die diese Mängel aufgrund der strengeren Natur von JSON umgehen können. Der Versuch, Modelle für einen der in diesem Thread erwähnten YAML-Deserialisierer zu erstellen, ist ein Albtraum, wenn und wo dies möglich ist.

Zugegeben, Modelle sind derzeit in den JSON-Cmdlets nicht verfügbar, obwohl ich sie wirklich gerne hinzufügen möchte. Wenn ich im "offiziellen" YAML-Modul / Cmdlets mitreden würde, würde ich es als "Muss" -Funktion ablegen. Dies ist eine verpasste Gelegenheit, insbesondere durch das Hinzufügen von PowerShell-Klassen in Version 5.

IMO, nur YAML-Strings in ein Objekt zu bekommen, ist nicht gut genug. Das scheint einfach zu sein (mindestens 90% der Zeit). Der Trick besteht darin, YAML-Strings in nützliche Objekte zu bekommen. Dies erfordert eine gewisse Flexibilität der Lösung. Diese Flexibilität muss aber auch einigermaßen @IISResetMe und @lzybkr dort Ratschläge zur Serialisierung geben.

Zu diesem Zweck habe ich nichts gesehen, was allgemein funktioniert. Die Projekte übernehmen die verfügbaren Lösungen und verwenden ihre Ausgabe dann als Vermittler für tatsächlich nützliche Objekte (was zu einer Reihe von Rad-Neuerfindungen führt, die wahrscheinlich vorgelagert gebacken werden sollten). Oder die Projekte beeinträchtigen die Lesbarkeit von YAML, um das Parsen von YAML auf Objekte zu vereinfachen.

@ Gaelcolas

Ich bin damit einverstanden, dass die YAML-Unterstützung von zentraler Bedeutung ist, anstatt dass das PS-Team von Grund auf neu schreibt. Warum nicht den bestehenden Projektbetreuern helfen, sich zu verbessern, und ihnen die Möglichkeit geben, Projekte zusammenzuführen und von ihnen zu hören, was erforderlich ist?

Fragen Sie sich, warum MSFT das .Net Core-Projekt gestartet hat, anstatt Mono viele Jahre später fortzusetzen.

MSFT ist auch eine Community. Und da jede Community die gleichen Probleme bei der Interaktion mit anderen Communities hat.

Für den Kontext impliziere ich nicht, dass Arbeiten von Grund auf neu ausgeführt werden - Code könnte übernommen werden -, sondern sollten dann aus Sicht der Systementwicklungsarchitektur überprüft werden, bevor sie verbessert werden. Nach dieser Überprüfung und erneuten Veröffentlichung könnte es sogar Open Source sein.

Mein Ziel ist es, eine umfassende Überprüfung und Korrektur der Architektur durch ein Team durchzuführen, das die Nuancen des Kerncodes, der praktisch überall eingesetzt wird, genau versteht.

Ein weiteres Modell, das immer in Betracht gezogen werden sollte, ist Erwerb / Vertrag / Sekunde. Auf dieser Grundlage wird versucht, mit einem oder mehreren Community-Mitgliedern / Firmen kommerzielle Bedingungen zu erreichen, um ihre Dienste für einen von MSFT geleiteten / erleichterten Entwicklungszyklus zu rekrutieren, um die Produkte neu zu gestalten und (in gewisser Weise) zu integrieren / zu verbinden. . Dies wurde erfolgreich mit Xamarin durchgeführt, das das Projekt an die Net Foundation übertrug, es unter MIT lizenzierte und über Xamarin Schlüsselressourcen wie Miguel de Icaza und Nat Friedman rekrutierte / beauftragte / einbezog. Einige jammern, dass dies Open-Source-Verrat ist. Es schafft jedoch positive Anreize für Leute und kleine Unternehmen, Projekte zu konzipieren und zu entwickeln, die später für eine breite Akzeptanz und Integration in mindestens ein großes Ökosystem geeignet sein könnten. Sicherlich ist es vorzuziehen, direkt zu einer leeren internen Wiederholung zu springen, die das gesamte Konzept und die Funktionalität sowie viele der Ideen kopiert, aber die Schöpfer und (angeblich) den Code über Bord wirft.

@iSazonov Entschuldigung für eine späte Antwort, nein, der platyPS yaml Parser ist nicht gut: Er unterstützt nur Schlüsselwertpaare. Wir verwenden YamlDotNet auch, um dort Yaml zu generieren.

In Bezug auf die Einstellung, dies aus dem Kernfeatureset herauszuhalten: Es gibt einen sehr signifikanten Unterschied in der Art und Weise, wie PowerShell mit Abhängigkeiten umgeht, im Vergleich zu beispielsweise Ruby, Python oder Node.js.

Jede dieser Sprachen verfügt über Tools zur Abhängigkeitsverwaltung (Bundler, Pip, Npm / Garn), mit denen die Verwaltung externer Abhängigkeiten einfach und vor allem reproduzierbar ist. Etwas wie ein Gemfile/Gemfile.lock oder package.json/package-lock.json [,yarn.lock] das die einfache Installation aller erforderlichen Pakete ermöglicht und sicherstellt, dass Sie auf einem ganz bestimmten Patch-Level bleiben, ist meiner Meinung nach eine sehr wichtige Unterscheidung. Was macht Bibliotheken von Drittanbietern für etwas so Grundlegendes machbar?

Vielleicht gibt es etwas, das mit Nuget getan werden könnte, um dieses Problem zu lösen, aber ich habe noch nie Artikel gesehen, die Strategien / Muster für das Abhängigkeitsmanagement für PowerShell beschreiben. Die Galerie zu haben ist großartig, aber wenn Sie alle erforderlichen Pakete manuell installieren müssen, ist dies für eine signifikante Bereitstellung nicht mehr möglich.

bearbeiten:
Es scheint also, dass das, wonach ich suche, möglicherweise bereits verfügbar ist: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. Ich werde das testen, sobald ich einen Moment Zeit habe. Wenn es funktioniert, muss ich meine Position überdenken, ob dies ein Kernelement sein sollte oder nicht. Ich habe immer noch Schwierigkeiten, es mit der Tatsache in Einklang zu bringen, dass JSON eine Kernfunktionalität ist, aber ich nehme an, dass es als "kleinster gemeinsamer Nenner" angesehen werden könnte.

@bgshacklett macht einen super guten Punkt.

@ chuanjiao10 - Bitte beenden Sie störende Kommentare zu vielen Problemen in diesem Repository. Die richtige Lösung wäre nicht , sie in das Modul Microsoft.PowerShell.Utility und sie als separates Modul in der PowerShellGallery zu versenden

Wenn Sie nativ sagen, meinen Sie damit XML oder JSON?

Derzeit wird davon ausgegangen, dass YAML überhaupt nicht in PowerShell integriert werden sollte, sondern ein separates Modul, das Sie aktualisieren können, ohne eine neue Version von PowerShell zu erwerben.

Wenn YAML wie XML in PowerShell gebacken würde, wäre dies unmöglich (denken Sie an [xml] "b").

Wenn wir den JSON-Weg gehen würden, hätten Sie Cmdlets, die mit YAML arbeiten könnten - also nicht wirklich in PowerShell integriert, aber Sie hätten immer noch die Nachteile, PowerShell aktualisieren zu müssen, um YAML-Updates zu erhalten.

Persönlich, obwohl es sich wie das "Richtige" für den Posteingang anfühlt, werde ich vorschlagen, dass dies nicht das Richtige ist

@lzybkr Ich weiß, wir sagten, wir wollten keine neue Bibliothek

Vielleicht nicht in 6.0 Zeitrahmen, aber wir sollten darüber reden.

Der Versand eines externen Moduls ist meiner Ansicht nach viel besser, da es auf niedrigerer Ebene verwendet werden kann, und IMO ist es weniger die Aufgabe des PowerShell-Teams, dies zu tun, als vielmehr die Community, dies mit Hilfe des PowerShell-Teams voranzutreiben, um nach Möglichkeit eine hohe Qualität zu erreichen.

Wieder @ chuanjiao10 wurde zuvor entschieden, YAML-Cmdlets in # 2109 nicht in PowerShell Core zu platzieren, und wurde dann zu Recht abgelehnt, da es jetzt auch abgelehnt werden sollte.

hinsichtlich

Einigkeit ist Stärke. Ein Amerikaner, der ein Auto braucht, haben Sie gesehen, wie er zu Wal-Mart ging, um ein Rad zu kaufen, zu Amazon, um einen Motor zu kaufen und sich selbst zu kombinieren (DIY ein Auto)?

Der Vergleich eines Autos mit Software ist eine schlechte Analogie, wenn man bedenkt, dass die Komponenten im Auto von vielen verschiedenen Anbietern stammen und dann in ein brauchbares Produkt verpackt werden, das sich nicht von den von der Community entwickelten PowerShell-Modulen unterscheidet, die dann gemischt und angepasst werden können. in Skripten verwendet

In Bezug auf diesen Punkt

Die Hauptbibliothek ist eingebaut, dies ist sehr wichtig, da ich sonst sehe, dass convertfrom-json, convertto-json usw. auch in PowerShellGallery platziert werden sollte.

Ich habe mich für so viele der eingebauten Module wie möglich gemäß # 1979 ausgesprochen und möchte, dass PowerShell Core so schlank wie möglich ist, was in # 5681 weiter besprochen wurde

und re

Diskriminiere YAML nicht, schmeichle JSON nicht.

Ich diskriminiere weder Yaml noch schmeichele ich Json, da beide ihre Fehler haben, aber beide ihre Verwendung haben. Wenn ich in der Lage gewesen wäre, Json-Cmdlets nicht in PowerShell zu versenden, hätte ich genau das Gleiche getan wie hier.

Ich denke, es kann nützlich sein, diese Diskussion ein wenig neu zu gestalten. Wären insbesondere diejenigen, die dafür sind, dass YAML in die Kernsprache aufgenommen wird, bereit, bestimmte Anwendungsfälle aufzulisten, und warum reicht ein Modul in der PowerShell-Galerie nicht aus, um diesen Anwendungsfall zu behandeln? An diesem Punkt können wir eine anforderungsorientierte Diskussion führen und möglicherweise eine praktikable Lösung für das vorliegende Problem finden.

Mein Hauptanwendungsfall ist die Bare-Metal-Automatisierung sowohl des Betriebssystems als auch der Anwendungsbereitstellung. In mindestens einem Fall möchte ich eine YAML-Datei lesen, die mein Skript aufgerufen hat, um die Parameter zu verstehen.
In diesen Fällen, in denen eine Abhängigkeit von einem externen, für uns nicht SLAed ist, ist der Service häufig ein großes Nein-Nein. Dies kann sich auf die Skalierungsaktivitäten der Produktion auswirken.

Das ist mein Anwendungsfall für den Versand im elementarsten Footprint des Powershell-Kerns.

Ich schätze die lebhafte Diskussion, lasst uns versuchen, sie höflich zu halten :)

@ PowerShell / Powershell-Komitee hatte dies zuvor diskutiert. Wir sind uns einig, dass die Unterstützung von YAML angesichts der heutigen Verbreitung wichtig ist. Wir möchten auch, dass weitere Module, die wir derzeit in PSCore6 ausliefern, ausgezogen sind, sodass Sie mit einer minimalen Installation von PSCore6 beginnen und dann hinzufügen, was Sie benötigen (bei Metamodulen müssen Sie nicht mehr als 10 Module hinzufügen, nur eines für DevOps zum Beispiel). In Bezug auf YAML sollte derzeit davon ausgegangen werden, dass dies ein separates Modul sein sollte (ich kann ein Repo unter PowerShell org erstellen, wenn jemand bereit ist, mit dem Prototyping zu beginnen, mein Team verfügt derzeit nicht über die Bandbreite). Die Verwendung von YamlDotNet (oder einer anderen Bibliothek von Drittanbietern) ist in Ordnung, sobald die Bewertung unter technischen, lizenzrechtlichen und Support-Gesichtspunkten erfolgt ist (ähnlich wie bei der Abhängigkeit von Json.Net). Als wir uns das letzte Mal YAML und YamlDotNet angesehen haben, besteht das Problem darin, dass die Implementierungen von YAML sehr unterschiedlich sind und dass die Bibliothek nicht alles unterstützt, was es gibt (sogar einige beliebte).

Ich möchte nur sagen, dass die Unterstützung von YAML etwas ist, das das Team gerne in der Veröffentlichung nach 6.2 sehen möchte.

@ SteveL-MSFT Könnten Sie bitte einen Kommentar zum Problem und zu https://github.com/dotnet/corefx/issues/34578 abgeben

Meiner Meinung nach haben convertfrom-json, convertfrom-jaml den gleichen Status, entweder ausziehen oder einbauen.

Ich habe befürwortet, dass wir die JSON-Cmdlets aus dem Projekt entfernen sollten. Es gibt einige Änderungen, die viele gerne vornehmen würden, die ziemlich brechende Änderungen wären, aber sie können nicht vorgenommen werden, da die Cmdlets an PowerShell gebunden sind. Wenn Sie sie aus dem Projekt entfernen, können Sie die wichtigsten Änderungen in einer neuen Hauptversion des Cmdlets-Moduls vornehmen und PowerShell mit einer älteren Version ausliefern, die Abwärtskompatibilität bietet, aber Benutzern das Aktualisieren ermöglicht, wenn sie dies wünschen Ein großer Aufwand, externe Module wie dieses einzubeziehen, IMO.

Ich würde lieber aus unseren Fehlern mit JSON und Pester lernen, als YAML willkürlich gleich zu behandeln. Es sollte definitiv nicht Teil der Kernfunktionalität von PowerShell sein, aber definitiv eine Art offiziell unterstütztes Modul mit gemeinsamer Eigentümerschaft zwischen der Community und dem PS-Team haben.

Ich mag diese Idee. Das Verschieben der JSON-Cmdlets würde dazu beitragen, Workflow-Probleme zu lösen, die derzeit bei starken Abhängigkeiten von externen Modulen bestehen.

Yaml ist jedoch wichtig für Systemadministratoren und Skriptentwickler. Diese Benutzer benötigen yaml-Befehle.

Sie benötigen sie möglicherweise , dies bedeutet jedoch nicht, dass sie direkt in PowerShell aufgenommen werden müssen, da ein externes Modul mehr als akzeptabel ist und einen flexibleren Support-Lebenszyklus aufweist als alles, was im Kern-Repository gebündelt ist.

Ich muss sagen, dass die @ SteveL-MSFT-Idee eines DevOps Meta-Moduls auf lange Sicht wirklich der richtige Weg ist, da dies es verschiedenen Benutzersätzen ermöglicht, einen einfacheren Satz von Paketen zu erhalten, die viel einfacher zu verwalten sind als externe Abhängigkeit als als interne Abhängigkeit, was für mich in Zukunft sehr sinnvoll ist, obwohl es sich um Metamodule handeln sollte, die auf Tech-Stacks basieren, denn wenn ich unter Windows bin und kein Anisble verwende, warum sollte ich dann Yaml-Cmdlets benötigen? Fenster?

Während es in der Linux-Welt eine große Anzahl von Benutzern gibt, die yml verwenden, wie von @ chuanjiao10 erwähnt, ist dies in der Windows-Welt nicht der Fall, die nach meinem Verständnis der gesamten PowerShell-Nutzung immer noch weitgehend bei PowerShell 5.1 bleibt, da es auf ihren Systemen im Posteingang ist und während das Bündeln von Yaml-Cmdlets Linux-Benutzern helfen kann, scheint es mir ein unnötiges zusätzliches gebündeltes Element für Windows-Benutzer zu sein, aber um beide Benutzergruppen gleich zu behandeln, ist es äußerst sinnvoll, dass es sich letztendlich um ein externes Modul handelt, das beide Benutzergruppen verwenden kann nach Bedarf nutzen

Gibt es jemanden, der Eigentümer werden und diese Cmdlets in einem separaten Projekt begleiten möchte?

@iSazonov es scheint, dass corefx derzeit nicht an integrierter YAML-Unterstützung interessiert ist. YamlDotNet scheint die beliebteste Bibliothek zu sein, ist MIT-lizenziert, aktiv gewartet, also würde ich dort anfangen. Ein Community-gesteuertes Projekt wäre erstaunlich und würde wahrscheinlich früher stattfinden, als wenn Sie es dem PowerShell-Team überlassen würden.

@ SteveL-MSFT scheint das aus gutem Grund zu sein - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255, was meiner Meinung nach das Vertrauen in diese bestimmte Bibliothek verringert hat.

es scheint, dass corefx derzeit nicht an integrierter YAML-Unterstützung interessiert ist.

Das CoreFX-Team fragt nach Anwendungsfällen. Wenn das PowerShell-Projekt angibt, dass wir die API benötigen, wird das Hinzufügen der API in Betracht gezogen.

Ein Community-gesteuertes Projekt wäre erstaunlich und würde wahrscheinlich früher stattfinden, als wenn Sie es dem PowerShell-Team überlassen würden.

Oh, ich kenne nur ein solches Projekt - Pester. Und ich glaube nicht an das von der Yaml-Community betriebene Projekt - warum ist es in den letzten Jahren nicht aufgetaucht?
Ich denke darüber nach, das Projekt zu starten, aber es hat mich daran gehindert, dass ich niemals das Niveau an Qualität, Konformität und Sicherheit des Codes erreichen kann, das MSFT benötigt.
Ich denke, MSFT wird niemals in der Lage sein, Projekten ohne Sicherheitsüberprüfung zu vertrauen und sie zu verwenden.
Ich habe nur eine Idee, damit es funktioniert. MSFT GitHub-Projekte wie CoreFX und PowerShell sind "im Besitz von MSFT" und "von MSFT gesteuert". Der neue Projekttyp könnte "im Besitz von MSFT", "von der Community gesteuert" und "von MSFT betreut" sein. Unter "betreut" meine ich die Implementierung einer Umgebung, in der das Projekt vertrauenswürdig und von hoher Qualität ist.

Microsoft muss die YAML-Unterstützung im Posteingang für PowerShell Core bündeln. Schlicht und einfach.

@brettjacobson Ja, es wäre schlicht, einfach und von hoher Qualität, aber das MSFT-Team verfügt nicht über so viele Ressourcen. Bist du bereit, einen Beitrag zu leisten? :-)

@brettjacobson - Microsoft muss die YAML-Unterstützung nicht bündeln. Es kann von Nutzen sein, wenn sie es getan haben, aber es gibt keine Verpflichtung von ihnen, dies zu tun, und es besteht überhaupt keine Notwendigkeit, dies zu tun.

Dies ist eine Feature-Anfrage für etwas, das viele want und letztendlich use aber kein kritisches need und daher _ unwahrscheinlich_ priorisiert werden muss, was genau das ist, was @ SteveL-MSFT ist versuchte zu erreichen, als er folgendes sagte

Ich möchte nur sagen, dass die Unterstützung von YAML etwas ist, das das Team gerne in der Veröffentlichung nach 6.2 sehen möchte.

Ein Community-gesteuertes Projekt wäre erstaunlich und würde wahrscheinlich früher stattfinden, als wenn Sie es dem PowerShell-Team überlassen würden.

Das PowerShell-Team ist nicht riesig. Wenn Sie dies realistisch betrachten, wird der beste und schnellste Weg, um Unterstützung für YAML zu erhalten, außerhalb der Kernfunktionen von PowerShell liegen, anstatt sich in das Produkt selbst einzubringen.

Das CoreFX-Team fragt nach Anwendungsfällen. Wenn das PowerShell-Projekt angibt, dass wir die API benötigen, wird das Hinzufügen der API in Betracht gezogen.

@iSazonov IMHO wird es in CoreFX niemals eine integrierte YAML-Unterstützung geben, da es noch keine vollständige JSON-Unterstützung gibt.

Warten Sie also auf eine "großartige" Bibliothek von Drittanbietern oder bitten Sie James Newton-King, ein Newtonsoft.Yaml zu erstellen? :-)

@NextTurn Wir werden eine neue Json-Implementierung (sehr schnell (schneller als Newton.Json) und sehr flexibel) in .Net Core 3.0 erhalten.
Das CoreFX-Team fügt immer eine neue API hinzu, wenn die Community große Anfragen stellt. Wenn es viele Projekte gibt, die von YAML profitieren können, werden sie hinzugefügt. Derzeit gibt es keine derartigen Anfragen.

Was mache ich nicht jedes neue pwsh System? Ich mache Install-Module -Name powershell-yaml .

Mongo, Kubernetes, Istio, Ansible, nennen Sie es - ich benutze. All dies sind YAML und ich habe YAML-Vorlagen und -Transformationen. pwsh scheint gut für DevOps zu sein und sie sprechen YAML.

@ dzmitry-lahoda Ausgabe Nr. 5681 schlägt vor, eine "reichhaltige" Version von PowerShell zu haben, die mit einer Reihe allgemeiner Module wie z. B. Pester usw. geliefert wird Ein klarer Gewinner zwischen den derzeit 2 verfügbaren Yaml-Modulen und sie kämpfen gegeneinander. Es könnte eine schwierige Entscheidung sein, einen Favoriten auszuwählen.

Ich sehe nur eine YAML :(

Pester , yeh. Im Gegensatz zum YAML-Reader für meine pwsh-Containeranwendungen ist es zu schwer, das BDD-Framework in die Hauptleitung zu integrieren.

Wurde dieser Thread abgeschlossen? Welches Modul wird von Microsoft empfohlen (oder empfohlen)?
DevOps-Pipelines verwenden Yaml. Alle meine Bereitstellungsautomatisierungen werden mit Powershell erstellt. Scheint, Yaml und Powershell spielen nicht gut. Ist Powershell eine schlechte Wahl für die Azure DevOps-Automatisierung?
Ich muss sorgfältig über meine zukünftige Verwendung / Innovation nachdenken und würde mich über eine Richtung freuen.
Danke im Voraus!

@dirkslab Sie können https://github.com/cloudbase/powershell-yaml verwenden

GitHub

Cloudbase / Powershell-Yaml

PowerShell CmdLets für die Manipulation des YAML-Formats. Tragen Sie zur Entwicklung von Cloudbase / Powershell-Yaml bei, indem Sie ein Konto auf GitHub erstellen.

Danke @iSazonov , das ist die Lösung, mit der ich gerade

Beachten Sie, dass Sie mit Powershell-Yaml ein nicht vertrauenswürdiges Modul in Ordnung bringen müssen. Dies ist der Teil, den ich zu verstehen kämpfe. Microsoft empfiehlt die Verwendung von Yaml-Pipelines. Microsoft (oder zumindest dieser Thread) schlägt vor, ein Modul eines Drittanbieters zu verwenden, damit Sie yaml config in Powershell integrieren können, aber keine unterstützen oder empfehlen. Wie erklären Sie das dem Unternehmen logisch?
Bisher habe ich immer die Erfahrung gemacht, dass, wenn Sie keine von Microsoft empfohlenen Lösungen verwenden, die Unterstützung oder das Verständnis von Microsoft für Ihre Lösungsprobleme stummgeschaltet wird (dies spielt keine Rolle, wenn der nicht unterstützte Teil etwas berührt, das Probleme verursacht). Die bloße Tatsache, dass Sie ein nicht unterstütztes Teil haben, führt normalerweise zu keiner Unterstützung / Verantwortung.
Vielleicht haben sich die Dinge in dieser OpenSource-Ära geändert. Eine einfache offizielle Antwort und Anleitung von Microsoft würde mich beruhigen und mir helfen, zu verstehen.

Ich habe Ihre Antwort geschätzt. Grüße.

@dirkslab Ich denke, Ihr MSFT Account Manager ist die richtige Person, um nach Supportrichtlinien zu fragen.

Das CoreFX-Team fragt nach Anwendungsfällen

Abgesehen von den offensichtlichen Vorteilen, dass Yaml heute in CI / CD und der Anzahl der Konfigurationssysteme allgegenwärtig ist, besteht der zusätzliche Vorteil von ConvertTo-Yaml darin, dass im Gegensatz zu ConvertTo-Json , das wir jetzt verwenden müssen, gefälschte HashTable in einem für Menschen lesbaren Format dargestellt wird was die Ausgabe nicht sehr lesbar macht.

Ich benutze in der Zwischenzeit

Ich hasse Yaml, ich hasse es wirklich. Es gibt jedoch einige Facetten, die das MS-Team berücksichtigen sollte:

1. Es ist die defacto-Sprache von CI geworden: docker-compose.yaml, ansible, kuber, k8s, github, circle, azure, ... und es scheint aus CI in die Projekte zu kriechen, die es verwenden.

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

Dieses Schiff mit Powershell zu haben, würde die Evangelisierung zu CI-Gruppen verändern.
"Wenn wir zu ms Powershell wechseln, können wir automatisch" -> "Erzähl mir mehr?"
vs.
"Wenn wir zu ms Powershell wechseln und einige Skripte aus der Galerie herunterladen" -> "no"

1. Wirklich, dies ist nach und nach, aber yaml ist eine Obermenge von json, so dass json eine abgekürzte Form von yaml ist, ein effizienter yaml-Parser ist ein effizienter json-Parser.

Kann dies für 7.1 überdacht werden? Ich habe auch Probleme mit der Verwendung eines nicht vertrauenswürdigen Moduls und etwas, sodass DevsOpsy wirklich in PowerShell enthalten sein sollte.

Meiner Meinung nach ist YAML genauso beliebt wie JSON und CSV, und es ist traurig, keine Posteingangskonverter für YAML in PowerShell zu haben. Mit YAML-Konvertern im Posteingang wird auch sichergestellt, dass ihr Verhalten mit JSON-Konvertern vergleichbar ist, was bei Community-Modulen nicht der Fall ist.

Verstehen Sie mich nicht falsch - ich weiß zu schätzen, dass Leute Module für die Community erstellen, aber im gegenwärtigen Zustand der Welt steht die YAML-Konvertierung auf dem Spiel - wir erwarten nicht, dass Leute Module von Drittanbietern für die JSON-Konvertierung herunterladen.