Including open source libraries to support YAML cmdlets #2109

Activity

1. ArieHein commented on Aug 28, 2016

   

   Arie Heinrich (ArieHein)

   on Aug 28, 2016

   More actions

   Doug Finke (@dfinke) : Try looking at the Ansible repos from https://github.com/trondhindenes
   to see how he handled it as Ansible is YAML
2. ArieHein commented on Aug 28, 2016

   

   Arie Heinrich (ArieHein)

   on Aug 28, 2016

   More actions

   We discussed having a DSC resource to handle some common text files. YAML would fit there too.
   PowerShell/DscResources#155
3. dfinke commented on Aug 28, 2016

   

   Doug Finke (dfinke)

   on Aug 28, 2016

   Author

   More actions

   Arie Heinrich (@ArieHein) Could you say more about your comment? I've wrapped the YAMLDotNet library in PowerShell so I can do ConvertFrom-Yaml. Works fine. I was thinking it'd be good to add this to PowerShell directly so these cmdlets are available out of the box.

   I was thinking of pulling YAMLDotNet into the PowerShell code, and create a cmdlet for it. I wanted guidance on adding other oss into the core product. If v6.0 ships with Windows, are there legal restrictions? Is there a mechanism to add these types of cmdlets so it ships with the OSS version and not the Windows release? etc

   👍React with 👍2Reacted by Ryan Yates and Warren Frame
4. ArieHein commented on Aug 28, 2016

   

   Arie Heinrich (ArieHein)

   on Aug 28, 2016

   More actions

   The starting point was adding a DSC resource to handle various text formats. We didnt mention YAML as an option as implementing it would take longer time. Naturally it would be based on the appropriate .net classes and types (were not inventing the wheel).

   Trons' repo was something I found along the way when I was learning Ansible and he has created DSC resources to handle YAML, so I figured you might want to take a look if anything looks reasonable to you. Perhaps the core code is already inside PowerShell without bringing additional libraries.
5. kilasuit commented on Aug 28, 2016

   

   Ryan Yates (kilasuit)

   on Aug 28, 2016

   Collaborator

   More actions

   I agree with Doug Finke (@dfinke) that it would be good to get some guidance on whether it is possible to be able to add this directly in the PowerShell 6 release as this would also help where there are other possible options that could also be included from other OSS projects too
6. RamblingCookieMonster commented on Aug 29, 2016

   

   Warren Frame (RamblingCookieMonster)

   on Aug 29, 2016

   More actions

   This would be quite valuable. Yaml is a common format in the wider Microsoft ecosystem, and beyond. Some common use cases:

   • Introduce more opportunity for tooling and automation for systems using yaml for configuration
   • Provide an friendlier (IMHO - at the very least, "another") way to serialize and deserialize data for our own PowerShell tools

   Cheers!
7. vors commented on Aug 31, 2016

   

   sergei (vors)

   on Aug 31, 2016

   Collaborator

   More actions

   This raise the question "What should be available in the core distro and what should be downloadable from the gallery". Historically (before Windows PowerShell v5), it was hard to relay on any modules that are not part of the distro. With https://www.powershellgallery.com/ it became much easier to install and depend on 3rd party modules.

   👍React with 👍3Reacted by Warren Frame, Keith Hill and Wojciech Sciesinski
8. kilasuit commented on Aug 31, 2016

   

   Ryan Yates (kilasuit)

   on Aug 31, 2016

   Collaborator

   More actions

   sergei (@vors) - personally it makes sense for as much to be pushed to gallery as possible and "decoupled" from the core of PowerShell where I've rationalised why in #2136 & #1979

   But saying that I feel that any ConvertTo/ConvertFrom cmdlets like the proposed YAML ones should really be bundled into Microsoft.PowerShell.Utility.

   But then again that's just my thoughts 😉
9. RamblingCookieMonster commented on Aug 31, 2016

   

   Warren Frame (RamblingCookieMonster)

   on Aug 31, 2016

   Last edited by RamblingCookieMonster

   More actions

   I'd be for decoupling. Presumably, if it goes into PowerShell itself, it's locked to that and higher versions of PowerShell (and difficult to update outside of that cadence, as you mentioned Ryan Yates (@kilasuit)).

   On top of that, presumably an external module could target down-level PowerShell versions. IMHO this alone, assuming you target PS3 or PS4, would justify a separate module - many of us on the operations side don't have a choice, or aren't ready to move to PS5+ across the board - not everyone runs a farm of cattle unfortunately : )

   Cheers!
10. kilasuit commented on Aug 31, 2016

    

    Ryan Yates (kilasuit)

    on Aug 31, 2016

    Collaborator

    More actions

    This is where module metadata in the PowerShell Gallery plays a very important role. Even modules released to the Gallery can be downloaded without having PackageManagement installed using something like this

    $file = 'https://www.powershellgallery.com/api/v2/package/ISESteroids/2.6.0.3'
    $Request = [System.Net.WebRequest]::Create($file)
    $Request.Timeout = '1000000000'
    $URL = $Request.GetResponse()
    $Filename = $URL.ResponseUri.OriginalString.Split('/')[-1]
    $WC = New-Object -TypeName System.Net.WebClient
    $WC.DownloadFile($file,('C:\Files\{0}' -f $Filename))
    $WC.Dispose()
    $URL.Close()

    So things like PowerShellVersion & PowerShellHostName etc should be filled in where possible - else why bother having the metadata available to us in the first place?
11. Steve Lee (SteveL-MSFT)

    added

    Issue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bug

    WG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issues

    on Sep 1, 2016
12. vors commented on Sep 11, 2016

    

    sergei (vors)

    on Sep 11, 2016

    Collaborator

    More actions

    Based on the discussion, our resolution is: we will keep YAML parsing capabilities outside of the scope for PowerShell core (inbox modules) in the observable future.
    We are encouraging you to use PowerShell gallery as a delivery vehicle for the module.
13. sergei (vors)

    closed this as completedon Sep 11, 2016
14. dfinke commented on Sep 20, 2016

    

    Doug Finke (dfinke)

    on Sep 20, 2016

    Author

    More actions

    Just another data point.

    AWS CloudFormation Introduces YAML Template Support

    https://aws.amazon.com/about-aws/whats-new/2016/09/aws-cloudformation-introduces-yaml-template-support-and-cross-stack-references/

    👍React with 👍1Reacted by Brian G. Shacklett
15. bgshacklett commented on Oct 27, 2016

    

    Brian G. Shacklett (bgshacklett)

    on Oct 27, 2016

    More actions

    I understand that every feature needs a business case. Currently, YAML is supported by pretty much every language out there, except for PowerShell. When I tell my coworkers that they should be looking into PowerShell on Linux or Mac OS, and then I say they're going to have to add another external library to handle YAML, it's going to seriously hurt PowerShell's position relative to other languages.

    👍React with 👍4Reacted by Igor, Peter Vandivier, Paul Kathro and Ben Himsel
16. iSazonov commented on Oct 27, 2016

    

    Ilya (iSazonov)

    on Oct 27, 2016

    Collaborator

    More actions

    If this language is so important and needful (is it really true?), I see three direction to add support it:

    1. Module as external package
    2. New System.Yaml namespace in CoreCLR
    3. Native Yaml cmdlets and native [yaml](easy after 2.)
17. ArieHein commented on Oct 28, 2016

    

    Arie Heinrich (ArieHein)

    on Oct 28, 2016

    More actions

    Brian G. Shacklett (@bgshacklett) hmm what language supports YAML as a core type ? even python requires 'another external library'. So I cant see how this will 'hurt' PowerShell position.

    Ilya (@iSazonov) I dare say there wont be a System.Yaml for the same reason there's no System.JSON (not counting Silverlight) though you have some abilities via Serialization but this is left for the 3rd party to
    create their own implementations and not be bound. MS are good at making frameworks with enough hooks for the programmers to build upon and extend and thus create a partner ecosystem.

    As Warren Frame (@RamblingCookieMonster) said, decoupling is a good thing as you're not bounding the language to a specific implementation.

    👍React with 👍1Reacted by sergei