Repository navigation
ConvertFrom-Yaml, ConvertTo-Yaml #3607
Description
Would be great to support Yaml natively.
This was also mentioned by Fabien Dibot (@fabiendibot) on #3046
It would also be nice if the CMDLets had the goal of cleanly handling conversion of objects that came from XML as it seems like it would be a frequent use case. Maybe some good tests around this conversion?
Reacted by Arie Heinrich, Michael Klement, Mikey Lombardi (He/Him), Hiroyuki Kano, Anatoly Kulakov, Ravikanth C, Wojciech Sciesinski, Eduard Malakhov, Andy Schwabe, Adrian Calinescu and 220 more
Reacted by dzmitry-lahoda, Erik Anderson, John McCarthy, Christopher Blodgett, David Lenihan, RamblingPSTech, M1 Cloud, Kakaranish, Raimund Andrée, Andy Jordan and 4 more
Activity
ArieHein commentedon Apr 20, 2017
We had a similar discussion from DSC aspect,
allowing us to change json based configuration files, we wanted to have options for modifying xml based files, YAML based files ,INI based files supporting RegEx swaps from within Text Manipulation cmdlets.
Lack of existing support in PS means we have to work hard to get such ability.
It has been on hold pending community contribution, but if it was baked into PS, it would make it much easier for the DSC part as well.
lzybkr commentedon Apr 20, 2017
When you say natively, do you mean like XML or JSON?
The current thinking is that YAML should not be baked into PowerShell at all, instead it should be a separate module that you can update without picking up a new version of PowerShell.
If YAML were baked into PowerShell like XML, that would be impossible (think [xml]"b")
If we went the JSON route, you'd have cmdlets to work with YAML - so not really baked into PowerShell, but you'd still have the drawbacks of needing to update PowerShell to get YAML updates.
joeyaiello commentedon Apr 20, 2017
Jason Shirk (@lzybkr) I know we said we didn't want to bring in a new library, but I think this is something we might need to reassess. Ideally, we should also ship the module on the Gallery, but I think a TON of modern scenarios require YAML now.
Maybe not in 6.0 timeframe, but we should talk about it.
DarwinJS commentedon Apr 20, 2017
Arie Heinrich (@ArieHein) - I have some simple functions that save and retrieve a hash array to the registry. Only handle REG_SZ - but for a simple set of settings it is sufficient - let me know if you want a copy.
I mispoke when I said "native" - I primarily meant "built-in" - it wouldn't bother me if they were shipped-in script modules that could be updated.
iSazonov commentedon Apr 21, 2017
Our first discussion #2109
DarwinJS commentedon Apr 21, 2017
Ilya (@iSazonov) - ah yes I see!
I noticed the reference to AWS support of YAML on the thread - I have been converting some templates and have found this to helpful: https://github.com/awslabs/aws-cfn-template-flip
joeyaiello commentedon Apr 21, 2017
Ilya (@iSazonov) thanks for the pointer, I couldn't find it for some reason. Remember it well, though.
In re-reading that original thread, I think we should definitely implement the cmdlets at some point in the future, and ship them in the Gallery. Based on their quality, and people's perceived usefulness (along with some refactoring work we hope to do after 6.0.0), we can make the in-box vs. Gallery-only call.
iSazonov commentedon Oct 8, 2017
We have Yaml in https://github.com/PowerShell/platyPS
MattTunny commentedon Oct 25, 2017
yeah this would be awesome to have, ended up using https://github.com/awslabs/aws-cfn-template-flip to convert
iSazonov commentedon Oct 25, 2017
Matt Tunny (@MattTunny) Welcome to contribute! :-)
josepmv commentedon Dec 1, 2017
There's a Windows Server user voice openned to vote for it :-)
https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11088495-out-of-the-box-support-for-yaml-like-csv-xml-j
84 remaining items
Vaccano commentedon Aug 20, 2021
This makes me sad.
Powershell says ".Net has to do it for us to do it"
.Net says "It is up to Powershell if they want to do it"
I wonder if some of the higher ups at Microsoft realize the runaround that is going on here.
YAML is important. Having it from a signed Trusted Source is critical for most companies. Powershell has built in restrictions making it hard to use things not signed by trusted sources.
I give up. It seems that the enough dust has been kicked up to obscure this issue. I imagine at some point someone high up at Microsoft will say "What? No YAML support in PowerShell?" Fingers will be pointed, blame laid, excuses made (etc). Then it will get done. But no amount of requests by the community will get this through.
awakecoding commentedon Aug 24, 2021
Why has this been closed as WONTFIX? Seriously, YAML is so common these days, all the cloud-native stuff uses it. One can do so much with just vanilla PowerShell before they need to import a module, and not being to deal with YAML shouldn't be one of them. The built-in JSON cmdlets is one of the reasons why JSON is to popular in PowerShell: it's there, it's standardized, and it works. I am sure I am not alone defaulting to JSON just for that reason, and thinking twice about using YAML if I don't really need it, as it makes my scripts less portable or standalone.
JustinGrote commentedon Aug 24, 2021
Marc-André Moreau (@awakecoding) joey's explanation is here: #3607 (comment)
The Json library, even though it was Newtonsoft, was "blessed" by Microsoft as the official JSON library till system.text.json came around.
It's a bummer for sure, I would love native YAML support as well, but I personally think the reasoning is sound. I think energies should be focused on more easily pulling down dependencies quickly for a script/module.
StephenHodgson commentedon Jan 12, 2022
Seriously surprised this isn't already included. It is sorely needed in the community and would seem like a obvious inclusion.
schittli commentedon Jan 20, 2022
It's a shame.
We pay many billions in royalties and still have to beg M$ for many years so that not Amazon or Google don't step in again to solve such "problems".
Yes, it's a shame.
schittli commentedon Jan 21, 2022
After 5 years, it's time to ask M$$ again to do its homework, especially because we need YAML on azure.
Please vote:
#16785
mubed commentedon May 19, 2023
Please re-open this issue. This feature is really necessary.
JustinGrote commentedon May 19, 2023
mubed Probably won't happen until MS releases a first party YAML library:
#3607 (comment)
Several YAML modules available on the gallery though:
https://www.powershellgallery.com/packages?q=yaml
ronascentes commentedon Jan 9, 2024
Native YAML support in PowerShell is extremely necessary nowadays. We have to remember that PowerShell was primary designed for IT professionals and system administrators which most of cases have to deploy vanilla PowerShell scripts over the production environment because they cannot deploy modules (no internet connection, security constraints, not signed binaries etc). Also the module footprint is a concern. A single 2KB script that connects to SQL Server requires a 50 MB Sql Server module to work. If an script requires more than one module, I cannot imagine how much disk space would be required. NPM packages feeling? I really does not understand this concern of PowerShell team of not changing the standard library. Are PowerShell going to the same Javascript path?
JustinGrote commentedon Jan 9, 2024
Rodrigo Nascentes (@ronascentes) it's pretty simple. There is no first-party Microsoft YAML library (there is a JSON one and hence why its there), so having a first-party YAML support brings all kinds of licensing and whatnot issues until that happens.
Fortunately there's lots of great community modules, my favorite being YaYaML.
https://github.com/jborean93/PowerShell-Yayaml
Just run
install-module yayamland you're good to go.Alternatively, ask the .NET team to ship a yaml library with the BCL or ship a microsoft first-party one. YAML isn't native in dotnet as a whole either.
Vaccano commentedon Jan 9, 2024
Rodrigo Nascentes (@ronascentes) - It is two parts of Microsoft pointing the finger at the other. The PowerShell team says that they need a YAML parser built into .NET before they can add native YAML support to PowerShell. The PowerShell team says it does not have the manpower to build and maintain a .NET YAML parser, and thus cannot add native YAML support PowerShell. (They are unwilling add native YAML support based on a community YAML parser. This is due to licensing and support issues.)
The .NET team says there is not a need for a native .NET YAML parser. They site that there is a fine community YAML parser already out there. Because of this, they are unwilling to build a YAML parser into .NET. They say that if PowerShell needs a YAML parser, they need to build and maintain their own parser. (Which the PowerShell team says they cannot do.)
So basically, it is one company (Microsoft) acting as two companies (PowerShell and .NET). The two parts of Microsoft are unwilling to get together and make a plan to fix this situation. Until a high level Microsoft executive looks and say "What?!?! We don't have YAML support?!?! FIX IT!!", we will get no change to this deadlock. (And no native YAML support in PowerShell.)
StephenHodgson commentedon Jan 9, 2024
Same thing was said about json, yet we have System.Text.Json today 🤷
JustinGrote commentedon Jan 9, 2024
Stephen Hodgson (@StephenHodgson) agreed, and as soon as the dotnet team recognizes that and ships System.Text.Yaml in Dotnet 11 (or whatever), I'm sure a first party PS module will be soon to follow :)
It will take someone thinking that the existing libraries are not "good enough" in the same way it was determined for NewtonSoft. Honestly surprised as much of a Not-Invented-Here culture that exists over there that it hasn't happened sooner.
Related Discussion FYI: dotnet/runtime#83313
m3nax commentedon Jan 16, 2024
Without JSON patch support...
JustinGrote commentedon Jan 16, 2024
You could make a module for that using this library.
https://github.com/weichch/system-text-json-jsondiffpatch