I made a 2 new go-yaml helper libraries today for querying and manipulating yaml/go-yaml Node struct graphs (aka the representation graph) and one is based on yq.
This was my eventual response to yaml/go-yaml#289 and yaml/go-yaml#353
Adding node.Merge to go-yaml is problematic because of the myriad merge options needed and because once you have merge you want a lot more.
I realized that yq is one pretty slick version of a DOM API. At first I was going to just add a Yq method to go-yaml-dom, but I realized that most users would want one or the other, and that yq would be a little bit of a big dependency for a generic dom (which is essentially dep free).
I looked into doing this with libyq but decided to temporarily copy the guts over until the PoC was proven valuable. I definitely don't want to maintain a forked yq code base.
@mikefarah I DM'd you on CNCF slack, but I'm not sure if you check that much these days.
Let me know what you think about this...
I made a 2 new go-yaml helper libraries today for querying and manipulating yaml/go-yaml Node struct graphs (aka the representation graph) and one is based on yq.
This was my eventual response to yaml/go-yaml#289 and yaml/go-yaml#353
Adding node.Merge to go-yaml is problematic because of the myriad merge options needed and because once you have merge you want a lot more.
I realized that yq is one pretty slick version of a DOM API. At first I was going to just add a Yq method to go-yaml-dom, but I realized that most users would want one or the other, and that yq would be a little bit of a big dependency for a generic dom (which is essentially dep free).
I looked into doing this with libyq but decided to temporarily copy the guts over until the PoC was proven valuable. I definitely don't want to maintain a forked yq code base.
@mikefarah I DM'd you on CNCF slack, but I'm not sure if you check that much these days.
Let me know what you think about this...