Powershell: ConvertFrom-Yaml, ConvertTo-Yaml

У нас было подобное обсуждение с точки зрения DSC ,
позволяя нам изменять файлы конфигурации на основе json, мы хотели иметь параметры для изменения файлов на основе xml, файлов на основе YAML, файлов на основе INI, поддерживающих подкачки RegEx из командлетов текстового манипулирования.

Отсутствие поддержки в PS означает, что нам нужно много работать, чтобы получить такую ​​возможность.
Он был приостановлен в ожидании вклада сообщества, но если бы он был встроен в PS, это значительно упростило бы и часть DSC.

Когда вы говорите "изначально", вы имеете в виду XML или JSON?

В настоящее время считается, что YAML вообще не следует встраивать в PowerShell, вместо этого он должен быть отдельным модулем, который можно обновлять, не выбирая новую версию PowerShell.

Если бы YAML был встроен в PowerShell, как XML, это было бы невозможно (подумайте [xml] " b ")

Если бы мы пошли по маршруту JSON, у вас были бы командлеты для работы с YAML - так что на самом деле они не встроены в PowerShell, но у вас все равно будут недостатки, связанные с необходимостью обновления PowerShell для получения обновлений YAML.

@lzybkr Я знаю, что мы сказали, что не хотим вводить новую библиотеку, но я думаю, что нам, возможно, придется пересмотреть это. В идеале мы также должны отправить модуль в Галерею, но я думаю, что сейчас YAML требуется ТОННА современных сценариев.

Возможно, не в таймфрейме 6.0, но об этом стоит поговорить.

@ArieHein - у меня есть несколько простых функций, которые сохраняют и извлекают хэш-массив в реестр. Обрабатывать только REG_SZ - но для простого набора настроек этого достаточно - дайте мне знать, если вам нужна копия.

Я неправильно сказал, когда сказал «родной» - я в первую очередь имел в виду «встроенный» - меня бы не беспокоило, если бы они поставлялись с модулями сценария, которые можно было бы обновлять.

Наше первое обсуждение # 2109

@iSazonov - ах да понятно!

Я заметил ссылку на поддержку YAML в AWS - я конвертировал некоторые шаблоны и нашел это полезным: https://github.com/awslabs/aws-cfn-template-flip

@iSazonov спасибо за указатель, почему-то не нашел. Но запомните это хорошо.

Перечитывая эту исходную ветку, я думаю, что мы обязательно должны реализовать командлеты в какой-то момент в будущем и отправить их в галерею. Основываясь на их качестве и восприятии полезности людьми (наряду с некоторой работой по рефакторингу, которую мы надеемся выполнить после 6.0.0), мы можем сделать вызов «входящие» или «только галерея».

У нас есть Yaml в https://github.com/PowerShell/platyPS

да, это было бы здорово, в конечном итоге использовал https://github.com/awslabs/aws-cfn-template-flip для преобразования

@MattTunny Добро пожаловать! :-)

Голосовать за него можно голосом пользователя Windows Server :-)

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

Это обязательно должно быть частью встроенной библиотеки PS 6.1. В YAML сейчас так много всего.

Теперь в PSGallery есть модули psyaml и powershell-yaml но оба они даже не могут передавать YAML-файл в оба конца из определения сборки VSTS. Я не возражаю, если модуль запечен в PowerShell или является модулем из PSGallery.

Интересно, заключается ли основная проблема здесь в неуклюжем способе развертывания модулей. Сегодня вы должны найти, доверять и установить модуль, прежде чем вы сможете его использовать. Сравните это с (очевидно) изящным способом, которым Javascript делает var m = require('mymodule') . Может быть, у нас должен быть какой-то способ сделать то, что делает DSC, но для собственной оболочки PowerShell. В DSC, когда модуль упоминается в конфигурации, он автоматически загружается и устанавливается на целевой узел без каких-либо ручных усилий. Обеспечение доступности критически важных, но неосновных модулей должно устранить аргументы «они должны быть частью ядра». А для узлов, которые отключены от сети, у нас может быть инструмент, который объединяет зависимости в сценарии в архив, который затем развертывается в целевом объекте. Вот как работает расширение ресурсов Azure DSC: есть инструмент, который сканирует сценарий, чтобы определить необходимые модули, а затем создает zip-файл, содержащий все необходимое, и публикует его в большом двоичном объекте. Затем расширение ресурсов Azure извлекает этот большой двоичный объект, устанавливает модули и запускает сценарий.

Для чего-то такого важного я действительно никогда не хочу зависеть от сторонней библиотеки, если у меня нет способа ее продать. Сторонним разработчикам слишком легко потенциально разрушить целые экосистемы (см. Https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/).

Помимо более широких проблем, в настоящее время нет хорошего модуля YAML для PowerShell, как указал

@bgshacklett Из того, что я слышал от парней из Puppet, хороших парсеров YAML просто нет :-)

Достаточно ли хорош парсер platyPS?

@vors Есть ли простой способ повторно использовать синтаксический анализатор YAML platyPS в репозитории PowerShell Core?

Я предпочитаю идею отдельного официального модуля в галерее PowerShell, как говорит @lzybkr, потому что его можно было бы использовать в более старых версиях PowerShell, и он мог бы иметь свои собственные выпуски. Это было бы похоже на модуль sqlserver . @BrucePay, если бы это была страница в галерее PowerShell с собственными модулями Microsoft, ее было бы легче найти, и все знали бы, что им можно доверять.

Но я бы понял, если бы он был поддержан в Powershell как XML и JSON.

Важно то, что существуют официальные функции ConvertFrom-YAML и ConvertFrom-YAML потому что YAML является широко используемым форматом для файлов конфигурации и не должен быть сторонним модулем, как указывает @bgshacklett .

Я провел тестирование записи в PSYaml и powershell-yaml .

У них разное поведение, потому что внутри они используют разные объекты:

| модуль | сопоставления | последовательности |
| --------- |: -------------- | ----------- |
| ПСЯмл | OrderedDictionary | Массив |
| powershell-yaml | Хастабл | Список |

Думаю, нам нужны стандартные ConvertFrom-YAML и ConvertFrom-YAML .

На самом деле ConvertFrom-Yaml в powershell-yaml использует OrderedDictionary при преобразовании с параметром -ordered .
Я уже некоторое время успешно использую этот модуль (в моем модуле Datum для данных конфигурации DSC и с кухонным yamls), но у меня нет определения сборки vsts для тестирования.

Имейте в виду, что правильный способ называть это: get-content -Raw MyFile.yml | ConvertFrom-Yaml -Ordered (люди часто пропускают -Raw ).

Интересно, зачем нам нужен _официальный_ модуль Microsoft, увеличивая накладные расходы на MSFT и изобретая колесо ... Может быть, сначала попытаться внести свой вклад в уже существующий, добавить тесты, чтобы избежать регресса, открыть проблемы, чтобы убедиться, что владелец знает проблемы - лучший подход ...
Вы знаете, что происходит, когда вы пытаетесь создать стандарт из 99 существующих реализаций ...

И да, было бы лучше вне языка, я согласен, что управление зависимостями могло бы быть лучше, хотя объединение всего в PS не является решением.
Общая проблема с npm также является ошибкой в ​​процессе. Форк и повторная публикация исправили это в кратчайшие сроки, создание приложений из последней версии Интернета было причиной того, что так много живых приложений сломалось.

Я согласен с @gaelcolas. Я думаю, что это лучше, если каждый будет работать с владельцами существующего модуля сообщества для повышения и обеспечения качества.

Я просто добавлю, что тесты для такого проекта должны включать в себя работу с большим количеством реальных файлов YAML для таких вещей, как AppVeyor, Travis CI, VSTS, AWS CloudFormation и т. Д. По моему собственному опыту с десерилизацией YAML, я имел мало успеха с одним универсальным решением, и в конечном итоге пришлось изобретать велосипед несколько раз. В этом смысле я согласен с @BrucePay , что "хороших парсеров YAML просто нет".

Мы говорим об этом модуле platyPS, потому что он уже активно используется в среде справки PowerShell. Думаю, никто из MSFT не может сказать, насколько хорош этот модуль из-за Кодекса поведения. Они могут либо молча отвергнуть его, либо улучшить.
И хотя мы говорили об этом очень давно, я не понимаю, как мы могли бы использовать компоненты этого модуля здесь простым способом.
Возможно, @adityapatwardhan и @ SteveL-MSFT раскроют свои планы и сроки, особенно потому, что новый Help RFC уже находится в стадии эксперимента.

Лично я считаю, что я бы предпочел, чтобы больше модулей сообщества стали успешными и стали де-факто стандартными, чем требовали «официальных» модулей от Msft.

@iSazonov Одно дело - иметь решение, которое работает для сериализации / десериализации четко определенной схемы. Совсем другое дело - иметь решение, которое в целом работает со всеми схемами, совместимыми с YAML.

Я понимаю желание MSFT повторно использовать проекты сообщества для сокращения затрат. Но на самом деле ситуация такова, что MSFT может не использовать так много проектов сообщества:

• у многих плохой код, им не доверяют
• многие проекты - это один человек

Спецификации Powershell были опубликованы MSFT более 10 лет назад, но до тех пор, пока MSFT не сделал этого, никто не перенес их.
Проект OpenSSL существует уже много лет, но его никто не переносил на Windows, а MSFT этого не сделала.
MSFT обнаружил многие тысячи интерфейсов API, но сколько из них было перенесено на Unix?
Интересно, почему компания запустила свой проект .Net Core, а не повторно использует Mono?
PowerShell уже полтора года является проектом с открытым исходным кодом, но я вижу, что в этом репозитории только один человек из сообщества вносит систематический вклад в код @markekraus и только один человек делает систематический анализ @ mklement0.
Не думаю, что если разделить проект на части, то вклад будет больше.
Не думаю, что завтра ситуация изменится. Я бы не стал на это рассчитывать.

@markekraus Я очень надеюсь на http://yaml.org/spec/1.2/spec.html#id2802346 :-)

@iSazonov делает важные
Однако не следует предполагать, что отличный модуль YAML будет развиваться сам по себе в ближайшие годы. Реальность такова, что большинство модулей публикуются авторами, которые решили конкретную проблему и сделали доброе дело, опубликовав свой общий базовый код. Так мы получили 2 модуля, которые призваны решить одну и ту же проблему. В идеале нужно было бы объединить их, чтобы сосредоточить усилия, иначе в будущем они будут расходиться дальше или просто устареют, и скоро будет больше модулей, опубликованных другими людьми.
Основная проблема, связанная с наличием надлежащего парсера, указывает на то, что базовая (и значительная с точки зрения усилий) фундаментальная работа необходима и требуется для создания хорошего модуля YAML.
Я не эксперт по YAML, но это просто проблема самой свободной спецификации языка или конкретной интерпретации различными системами, такими как VSTS или AppVeyor, или это всего лишь отсутствие хорошего парсера?
Мне было неприятно писать YAML в VSCode и только при запуске в VSTS, чтобы получить ошибку, что парсеру VSTS это не нравится ...

Для меня этот разговор является примером проблемы «курирования кода / архитектуры» с открытым исходным кодом.

Открытый исходный код предоставляет хорошие идеи для посева и кодовые базы, но если ему не уделяется серьезного внимания архитектуры при принятии в качестве наиболее общего решения, то это 10 лет исправлений ошибок для элементов, о которых можно было бы позаботиться при достойном обзоре дизайна. .

В истинных случаях "зрелого успеха" @bergmeister часто бывает, что активный сопровождающий берет на себя задачу обобщения кодовой базы. Но это не может быть гарантировано.

Я думаю, некоторые из нас говорят: «Поддержка YAML похожа на поддержку записи файлов - это ядро ​​- он должен быть спроектирован таким же образом => с намерением стать золотым стандартом для этой функциональности»

Сочетание 1) полуархитектурного атрибута открытого исходного кода и 2) основной природы YAML, кажется, заставляет многих из нас стремиться к высоко архитектурному подходу, который, как мы знаем, разработчики Microsoft PowerShell применяют в своей работе. Это не обязательно отход от всех других интересных вещей, в которых нам действительно может помочь открытый код.

Очень веские аргументы в пользу зрелости программного обеспечения. Я не смотрел внимательно ни на два модуля, перечисленные здесь, ни на yamldotnet, чтобы составить какое-либо мнение. Что-то, на что мы можем взглянуть, когда начнем планировать 6.2.0

Не поймите меня неправильно, я ценю опыт и систематический подход команды PowerShell и разработчиков MSFT, я просто считаю, что с их стороны неправильно пытаться заполнить все пробелы с помощью модуля с собственной печатью MSFT ... не масштабируется (и мы уже видели проблему с ресурсами DSC).
Увеличение зависимости от модулей, предоставляемых MSFT, хрупко и не способствует росту сообщества или разнообразию экосистемы.
Я за то, чтобы MSFT вносила свой вклад в проекты с открытым исходным кодом, чтобы делиться своим опытом и помогать улучшать методы и качество, не создавая при этом зависимости от них (потому что вы знаете, белки ...!).
_MSFT как уникальный поставщик одобренных вещей_ - это старая модель, которую они уже пытаются освоить, и она не помогает сообществу поощрять такой подход (т.е. _Я буду ждать или стонать в Microsoft из-за того, что не решил мою проблему _ своего рода отношение в экосистеме OSS).

Я согласен с тем, что поддержка YAML является ядром, вместо того, чтобы команда PS переписывала с нуля, почему бы не помочь существующим сопровождающим проектов улучшить и не дать им возможность объединить проекты и услышать от них, что для этого потребуется. Немного похоже на обучение / наставничество от команды PS по основным функциональным модулям.
Просто переписать новый модуль звучит как реакция инженера на решение проблемы, которая не является инженерной проблемой. Переписывание модуля YAML - это _легкая_ инженерная задача для команды PS, но она не (помогает) решить проблему зрелости сообщества и не даст правильного стимула.
Однако вопрос о том, является ли Yaml стратегическим элементом для решения этой проблемы, является вопросом MSFT :)

@bergmeister

Я скажу, что не являюсь экспертом по YAML. Мне довелось провести некоторое исследование по этому поводу, когда я хотел встроить некоторые конфигурации AppVeyor, например yaml, в свой собственный franken-pipeline. Я посмотрел, как около дюжины проектов C # используют YAML. Поскольку проекты PowerShell используют YamlDotNet, я могу только предположить, что это не проще. Хотя я, по крайней мере, поигрался как с PSYaml, так и с powershell-yaml и менее внимательно посмотрел на несколько проектов PowerShell, которые их используют.

Я не эксперт по YAML, но это просто проблема самой свободной спецификации языка или конкретной интерпретации различными системами, такими как VSTS или AppVeyor, или это всего лишь отсутствие хорошего парсера?

Я подозреваю, что природа YAML читается людьми за счет того, что, возможно, его легче читать машинами. Эта парадигма удобства чтения распространяется на способ, которым авторы YAML пишут свои файлы YAML. Хотя результирующий YAML соответствует спецификации YAML, он анализируется так, чтобы его нельзя было использовать в коде без использования десериализованного объекта в качестве посредника для действительно полезного объекта.

То есть в 90% случаев проблема не в десериализации из YAML в объект, а в дизайне / архитектуре данных. Остальные 10% времени - это проблемы с синтаксическим анализом, которые я могу списать только на «YAML трудно разобрать, чувак». Однако десериализованные объекты часто лишь немногим более полезны, чем регулярное выражение того, что вы ищете ...

Например, защищенные строки в AppVeyor.yml

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

powershell-yaml и YamlDotNet конвертируют это в объект, но удачи в использовании без кучи логики. Если у вас есть такая логика, подходит для этой схемы, но как насчет другой?

Некоторые из этих проблем с дизайном данных мешают JSON, но (по моему опыту и мнению) намного проще создавать модели, которые могут обойти эти недостатки из-за более жесткого характера JSON. Попытка создать модели для любого из десериализаторов YAML, упомянутых в этом потоке, - кошмар, если и где это возможно.

Конечно, модели не являются функцией, доступной в настоящее время в командлетах JSON, хотя я бы очень хотел ее добавить. Если бы я имел право голоса в «официальном» модуле / командлетах YAML, я бы назвал его «обязательной» функцией. Это упущенная возможность, особенно с добавлением классов PowerShell в v5.

ИМО, просто получить строки YAML в объект недостаточно. Это кажется простым (по крайней мере, в 90% случаев). Хитрость заключается в том, чтобы преобразовать строки YAML в _useful_ объекты. Это требует от решения определенной гибкости. Но эта гибкость также должна быть в некоторой степени доступной и не требовать наличия @IISResetMe и @lzybkr, чтобы дать вам совет по сериализации ....

В этой связи я не видел ничего, что работало бы в общем масштабе. Проекты перенимают доступные решения, а затем используют их результаты в качестве посредников для действительно полезных объектов (что приводит к множеству изобретений колеса, которые, вероятно, следует внедрить в апстрим). Или проекты ставят под угрозу читаемость YAML для упрощения синтаксического анализа YAML на объекты.

@gaelcolas

Я согласен с тем, что поддержка YAML является ядром, вместо того, чтобы команда PS переписывала с нуля, почему бы не помочь существующим сопровождающим проектов улучшить и дать им возможность объединить проекты и услышать от них, что для этого потребуется

Спросите себя, почему MSFT запустила проект .Net Core вместо того, чтобы продолжить Mono много лет спустя.

MSFT - тоже сообщество. И как у любого сообщества такие же проблемы взаимодействия с другими сообществами.

Что касается контекста, я не подразумеваю, что какая-либо работа будет выполняться с нуля - код может быть принят, - но затем его следует тщательно изучить с точки зрения архитектуры разработки систем, прежде чем улучшать. После этого обзора и переиздания он может быть даже с открытым исходным кодом.

Я хочу, чтобы команда, которая досконально разбиралась в нюансах основного кода, использовала практически повсюду, должна была провести значительный архитектурный анализ и исправления.

Еще одна модель, которую всегда стоит рассматривать, - это покупка / контракт / секунда. На этой основе предпринимаются усилия по достижению коммерческих условий с одним или несколькими членами сообщества / фирмами, чтобы набрать их услуги для цикла разработки под руководством / при поддержке MSFT, чтобы обновить и (в некоторой степени) интегрировать / подключить продукт (ы). . Это было успешно выполнено с помощью Xamarin, который отправил проект в Net Foundation, лицензировал его в рамках MIT и набрал / нанял / задействовал ключевые ресурсы, такие как Мигель де Иказа и Нат Фридман, через Xamarin. Некоторые жалуются, что это измена с открытым исходным кодом. Но это действительно создает положительные стимулы для людей и небольших фирм придумывать и развивать проекты, которые впоследствии могут быть пригодны для широкого внедрения и интеграции по крайней мере в одну крупную экосистему. Конечно, предпочтительнее сразу перейти к чистому переделу, который копирует всю концепцию, функциональность и многие идеи, но отбрасывает создателей и (якобы) код.

@iSazonov извините за поздний ответ, парсер yaml platyPS не годится: он поддерживает только пары ключ-значение. Мы также используем YamlDotNet для генерации там yaml.

Что касается отношения к тому, чтобы исключить это из основного набора функций: существует очень существенная разница в том, как PowerShell обрабатывает зависимости по сравнению, скажем, с Ruby, Python или Node.js.

У каждого из этих языков есть инструменты управления зависимостями (bundler, pip, npm / yarn), которые делают управление внешними зависимостями простым и, что более важно, воспроизводимым. Наличие чего-то вроде Gemfile/Gemfile.lock или package.json/package-lock.json [,yarn.lock] которое упрощает установку всех необходимых пакетов и гарантирует, что вы остаетесь на очень конкретном уровне исправления, является очень важным различием, которое, на мой взгляд, что делает сторонние библиотеки возможными для чего-то столь фундаментального.

Возможно, что-то можно было бы сделать с Nuget для решения этой проблемы, но я никогда не видел статей, описывающих стратегии / шаблоны управления зависимостями для PowerShell. Наличие галереи - это здорово, но если вам нужно установить все необходимые пакеты вручную, это станет невозможным для какого-либо значительного развертывания.

редактировать:
Таким образом, похоже, что то, что я ищу, уже может быть доступно: https://docs.microsoft.com/en-us/powershell/wmf/5.0/psget_moduledependency. Я проверю это, как только у меня будет время. Если это сработает, мне нужно будет пересмотреть свою позицию относительно того, должен ли это быть основным элементом или нет. Мне все еще трудно согласовать это с тем фактом, что JSON является основной функциональностью, но я полагаю, что это можно считать «наименьшим общим знаменателем».

@bgshacklett делает очень хорошее замечание.

@ chuanjiao10 - пожалуйста, прекратите не включать их в модуль Microsoft.PowerShell.Utility и фактически отправлять их как отдельный модуль, размещенный в PowerShellGallery.

Когда вы говорите "изначально", вы имеете в виду XML или JSON?

В настоящее время считается, что YAML вообще не следует встраивать в PowerShell, вместо этого он должен быть отдельным модулем, который можно обновлять, не выбирая новую версию PowerShell.

Если бы YAML был встроен в PowerShell, как XML, это было бы невозможно (подумайте [xml] "b")

Если бы мы пошли по маршруту JSON, у вас были бы командлеты для работы с YAML - так что на самом деле они не встроены в PowerShell, но у вас все равно будут недостатки, связанные с необходимостью обновления PowerShell для получения обновлений YAML.

Лично это кажется "правильным" для почтового ящика, но я предполагаю, что это не совсем то, что нужно делать.

@lzybkr Я знаю, что мы сказали, что не хотим вводить новую библиотеку, но я думаю, что нам, возможно, придется пересмотреть это. В идеале мы должны _также_ отправить модуль в Галерею, но я думаю, что сейчас YAML требуется ТОННА современных сценариев.

Возможно, не в таймфрейме 6.0, но об этом стоит поговорить.

На мой взгляд, доставка внешнего модуля намного лучше, так как его можно использовать на нижнем уровне, и ИМО это не столько работа команды PowerShell, чтобы сделать это, а больше сообщество, которое управляет этим с помощью команды PowerShell, чтобы достичь высокого качества там, где это возможно.

Опять же, @ chuanjiao10 ранее было решено не помещать командлеты YAML в PowerShell Core в # 2109 и было справедливо отклонено тогда, так как это также должно быть отклонено сейчас.

относительно

Единство это сила. Вы видели, как американец, которому нужна машина, пошел в Wal-Mart, чтобы купить колесо, пошел в Amazon, чтобы купить двигатель, и собрался вместе (сделай сам автомобиль)?

Сравнение автомобиля с программным обеспечением - это плохая аналогия, учитывая, что компоненты в автомобиле поступают от многих разных поставщиков, а затем упаковываются в полезный продукт, который ничем не отличается от модулей PowerShell, разработанных сообществом, которые затем можно смешивать и сопоставлять. используется в скриптах

Что касается этого момента

Основная библиотека встроена, это очень важно, иначе я вижу, что convertfrom-json, convertto-json и т. Д. Также должны быть помещены в PowerShellGallery.

Я выступал за это для как можно большего числа встроенных модулей согласно # 1979 и хотел бы, чтобы PowerShell Core был как можно более экономичным, что было начато для дальнейшего обсуждения в # 5681

и повторно

Не дискриминируйте YAML, не льстите JSON.

Я не различаю Yaml и не хвалю Json, поскольку у обоих есть свои недостатки, но у обоих есть свое применение, и если бы я мог повлиять на отказ от отправки командлетов Json в PowerShell, я бы сделал то же самое, что и здесь.

Думаю, было бы полезно немного перефразировать это обсуждение. В частности, захотят ли те, кто выступает за включение YAML в основной язык, перечислить конкретные варианты использования и почему модуля в галерее PowerShell недостаточно для решения указанного варианта использования? На этом этапе мы можем провести обсуждение на основе требований и, возможно, найти работоспособное решение проблемы.

Мой основной вариант использования - автоматизация развертывания операционной системы и приложений без операционной системы. По крайней мере в одном случае я хочу прочитать файл YAML, который вызвал мой скрипт, чтобы понять параметры.
Часто в этих случаях из-за зависимости от внешнего, не связанного с нами SLA, услуга является огромным запретом. Это может повлиять на масштабирование производства.

Это мой вариант использования ядра PowerShell с минимальным объемом памяти.

Ценю живую дискуссию, давайте постараемся быть вежливой :)

@ PowerShell / комитет по PowerShell обсуждал это ранее. Мы согласны с тем, что поддержка YAML важна, учитывая, насколько она распространена сегодня. Мы также хотим, чтобы больше модулей, которые мы сейчас поставляем в PSCore6, были перемещены, чтобы вы начали с минимальной установки PSCore6, а затем добавили то, что вам нужно (с метамодулями вам не нужно добавлять 10+ модулей, только один за DevOps , например). Итак, что касается YAML, текущее мнение таково, что это должен быть отдельный модуль (я могу создать репозиторий в PowerShell org, если кто-то готов приступить к созданию прототипа, у моей команды сейчас нет пропускной способности). Использование YamlDotNet (или другой сторонней библиотеки) нормально, если оно оценивается с точки зрения технологий, лицензирования и поддержки (аналогично тому, как мы взяли зависимость от Json.Net). Однако в прошлый раз, когда мы посмотрели на YAML и YamlDotNet, проблема в том, что реализации YAML сильно различаются, и эта библиотека не поддерживает все, что есть (даже некоторые популярные).

Я просто скажу, что поддержка YAML - это то, что я хотел бы, чтобы команда рассмотрела выпуск post 6.2.

@ SteveL-MSFT Не могли бы вы прокомментировать проблему и https://github.com/dotnet/corefx/issues/34578? Можем ли мы использовать YamlDotNet или нам нужно более надежное API от CoreFX?

in. мое мнение таково, что пусть convertfrom-json, convertfrom-jaml имеют один и тот же статус, либо перемещены, либо встроены.

Я выступал за то, чтобы мы убрали командлеты JSON из проекта. Есть довольно много изменений, которые многие хотели бы внести, которые были бы довольно критичными, но они не могут быть внесены, потому что командлеты привязаны к PowerShell. Перемещение их из проекта позволяет нам внести основные изменения в новую основную версию модуля командлетов, а PowerShell будет поставляться с более старой версией, обеспечивающей обратную совместимость, но позволяющую пользователям обновлять, если они того пожелают ... Однако это так. огромная проблема с включением таких внешних модулей, IMO.

Я бы предпочел, чтобы мы учились на наших ошибках с JSON и Pester, чем произвольно относились к YAML таким же образом. Он определенно не должен быть частью основных функций PowerShell, но обязательно должен иметь какой-то официально поддерживаемый модуль с совместным владением между сообществом и командой PS.

Мне нравится эта идея. Перемещение командлетов JSON поможет выявить проблемы рабочего процесса, которые в настоящее время существуют из-за жесткой зависимости от внешних модулей.

Но yaml важен для системных администраторов, разработчиков скриптов. Этим пользователям нужны команды yaml.

Они могут нуждаться в них, но это не значит, что их нужно включать непосредственно в PowerShell, поскольку внешний модуль более чем приемлем и имеет более гибкий жизненный цикл поддержки, чем все, что входит в основной репозиторий.

Я должен сказать, что идея @ SteveL-MSFT о модуле DevOps Meta действительно является правильным способом для этого в долгосрочной перспективе, поскольку это позволяет различным пользовательским группам получить более простой набор пакетов, которыми намного легче управлять. как внешняя зависимость, чем внутренняя, что для меня имеет большой смысл в будущем, хотя они должны быть метамодулями, основанными на технических стеках, потому что если я нахожусь в Windows и не использую anisble, тогда зачем мне нужны командлеты yaml на окна?

Хотя в мире Linux существует большое количество пользователей, использующих yml, как упоминалось @ chuanjiao10, это не относится к миру Windows, который,

Есть ли кто-нибудь, кто хочет стать владельцем и сопровождать эти командлеты в отдельном проекте?

@iSazonov похоже, что corefx в настоящее время не заинтересован во встроенной поддержке YAML. YamlDotNet, кажется, самая популярная библиотека, она лицензирована MIT, активно поддерживается, так что я бы начал с нее. Проект, управляемый сообществом, был бы потрясающим и, вероятно, случился бы раньше, чем если бы вы оставили его команде PowerShell.

@ SteveL-MSFT кажется, что на то есть веская причина - https://snyk.io/vuln/SNYK-DOTNET-YAMLDOTNET-60255, что, как я полагаю, снизило доверие к этой конкретной библиотеке.

похоже, что corefx в настоящее время не заинтересован во встроенной поддержке YAML.

Команда CoreFX спрашивает о вариантах использования. Если в проекте PowerShell будет сказано, что нам нужен API, они рассмотрят возможность добавления API.

Проект, управляемый сообществом, был бы потрясающим и, вероятно, случился бы раньше, чем если бы вы оставили его команде PowerShell.

О, я знаю только один такой проект - Pester. И я не верю в проект сообщества yaml - почему он не появился в последние несколько лет?
Я собираюсь начать проект, но меня остановило то, что я никогда не смогу достичь того уровня качества, соответствия и безопасности кода, который требует MSFT.
Думаю, MSFT никогда не сможет доверять и использовать проекты без аудита безопасности.
У меня есть только одна идея, как заставить это работать. Проекты MSFT GitHub, такие как CoreFX и PowerShell, «принадлежат MSFT» и «управляются MSFT». Новый тип проекта может быть «принадлежащим MSFT», «управляемым сообществом» и «управляемым MSFT». Под «наставничеством» я подразумеваю создание среды, в которой проекту будут доверять и быть качественным.

Microsoft необходимо включить поддержку YAML для PowerShell Core. Легко и просто.

@brettjacobson Да, это было бы просто, просто и качественно, но у команды MSFT не так много ресурсов. Вы готовы внести свой вклад? :-)

@brettjacobson - Microsoft не нужно объединять поддержку YAML. Это может быть полезно, если они сделали это, но от них нет никаких требований и нет необходимости делать это вообще.

Это запрос функции для чего-то, что много want и в конечном итоге use но не является критическим need и поэтому _ маловероятно_ получить приоритет, что и есть @ SteveL-MSFT пытался понять, когда он сказал следующее

Я просто скажу, что поддержка YAML - это то, что я хотел бы, чтобы команда рассмотрела выпуск post 6.2.

Проект, управляемый сообществом, был бы потрясающим и, вероятно, случился бы раньше, чем если бы вы оставили его команде PowerShell.

Команда PowerShell невелика, и поэтому, если смотреть на этот реалистичный самый лучший и самый быстрый способ получить поддержку YAML, он будет внешним по отношению к базовому набору функций PowerShell, а не встроиться в сам продукт.

Команда CoreFX спрашивает о вариантах использования. Если в проекте PowerShell будет сказано, что нам нужен API, они рассмотрят возможность добавления API.

@iSazonov IMHO никогда не будет встроенной поддержки YAML в CoreFX, так как еще не было полной поддержки JSON.

Так вы собираетесь дождаться «отличной» сторонней библиотеки или попросить Джеймса Ньютона-Кинга создать Newtonsoft.Yaml ? :-)

@NextTurn Мы получим новую реализацию Json (очень быструю (быстрее, чем Newton.Json) и очень гибкую) в .Net Core 3.0.
Команда CoreFX всегда добавляет новый API, если есть большой запрос от сообщества. Если есть много проектов, которые могут извлечь выгоду из YAML, они добавят. На данный момент таких запросов нет.

Что я не делаю в каждой новой pwsh системе? Я делаю Install-Module -Name powershell-yaml .

Mongo, Kubernetes, Istio, Ansible, назовите - я использую. Все это YAML, и у меня есть шаблоны и преобразования YAML. pwsh кажется хорошим для DevOps, и они действительно говорят на YAML.

@ dzmitry-lahoda В выпуске № 5681 предлагается иметь «богатую» версию PowerShell, которая поставляется с набором общих модулей, таких как, например, Pester и т. д. Пожалуйста, разместите в этом выпуске, но учитывая, что, похоже, нет явный победитель между двумя доступными в настоящее время модулями yaml, и они затирают друг друга, может быть трудным решением выбрать фаворит.

Я вижу только один YAML :(

Pester , ага. Слишком тяжело, чтобы включить BDD framework в основную версию, в отличие от программы чтения YAML для моих контейнерных приложений pwsh.

Эта тема завершена. Какой модуль рекомендуется (или предлагает) использовать Microsoft?
Конвейеры DevOps используют yaml. Вся моя автоматизация развертывания построена с помощью PowerShell. Кажется, что yaml и powershell плохо работают. Powershell - плохой выбор для автоматизации Azure DevOps?
Мне нужно хорошо подумать о моем будущем использовании / инновациях, и я был бы признателен за некоторые направления.
Заранее спасибо!

@dirkslab Вы можете использовать https://github.com/cloudbase/powershell-yaml

GitHub

Cloudbase / powershell-yaml

PowerShell CmdLets для управления форматом YAML. Участвуйте в разработке cloudbase / powershell-yaml, создав учетную запись на GitHub.

Спасибо @iSazonov , это решение, которое я сейчас тестирую. Решение пока работает нормально. Вероятно, в использовании решения нет ничего плохого.

Обратите внимание, что с помощью powershell-yaml вам нужно одобрить ненадежный модуль. Это та часть, которую я пытаюсь понять. Microsoft рекомендует использовать конвейеры yaml. Microsoft (или, по крайней мере, этот поток) предлагает использовать сторонний модуль, чтобы вы могли интегрировать конфигурацию yaml с powershell, но не одобряете и не рекомендуете их. Как вы логически объясните это предприятию.
Мой опыт до сих пор всегда заключался в том, что если вы не используете одобренные Microsoft решения, это отключит любую поддержку или понимание со стороны Microsoft в отношении ваших проблем (это не имеет значения, если неподдерживаемая часть касается чего-либо, вызывающего проблемы). Сам факт того, что у вас есть неподдерживаемая деталь, обычно не влечет за собой поддержки / ответственности.
Возможно, в эпоху OpenSource все изменилось. Простой официальный ответ и руководство от Microsoft успокоили бы меня и помогли понять.

Оценил ваш ответ. С уважением.

@dirkslab Я думаю, что ваш менеджер по работе с

Команда CoreFX спрашивает о вариантах использования

Помимо очевидных преимуществ того, что yaml сегодня повсюду вокруг нас в CI / CD, и количества систем конфигурации, дополнительное преимущество ConvertTo-Yaml представляет собой ужасный HashTable в удобочитаемом формате , в отличие от ConvertTo-Json который мы должны использовать сейчас что делает вывод не очень читаемым.

А пока я использую Write-HashTable , но было бы здорово иметь OTB.

Ненавижу ямл, очень ненавижу его. Однако есть пара аспектов, которые стоит рассмотреть команде MS:

1. Он стал де-факто языком CI: docker-compose.yaml, ansible, kuber, k8s, github, circle, azure, ... И, похоже, он выползает из CI в проекты, которые его используют.

$config = Invoke-WebRequest https://$ciserver/api/projects/$project/config.yaml | ConvertFrom-Yaml
$config['started'] = Get-Date
$config['options'] = $options
Invoke-WebRequest -Method Post https://$ciserver/api/projects/$project/build -Body ($config | ConvertTo-Yaml)

Наличие этого корабля с PowerShell изменило бы процесс евангелизации групп CI.
«Если мы переключимся на ms powershell, мы сможем автоматически» -> «Расскажи мне больше?»
против
«Если мы перейдем на ms powershell и скачаем какие-то скрипты из галереи» -> «нет»

1. На самом деле, это вскользь, но yaml - это надмножество json, так что json - это сокращенная форма yaml, эффективный парсер yaml - это эффективный парсер json,

Можно это пересмотреть на 7.1? У меня также возникают проблемы с использованием ненадежного модуля и чего-то еще, поэтому DevsOpsy действительно должен быть встроен в PowerShell.

IMHO, YAML так же популярен, как JSON и CSV, и отсутствие конвертеров входящих сообщений для YAML в PowerShell немного печально. Наличие конвертеров YAML для входящих сообщений также гарантирует, что их поведение будет на одном уровне с конвертерами JSON, что не относится к модулям сообщества.

Не поймите меня неправильно - я ценю, что люди создают модули для сообщества, но в текущем состоянии мира преобразование YAML - это ставки стола - мы не ожидаем, что люди будут загружать сторонние модули для преобразования JSON.