Open
Description
Currently the yaml library go-yaml/yaml no longer appears to be under active development, which means that some issues may not be solved upstream:
- Is this (v3) repo still maintained? go-yaml/yaml#788
- Is this library still maintained? go-yaml/yaml#776
So there are a couple of options right now
- Keep using
yaml.v2
. - Use
yaml.v3
and follow the v3 format (this option might as well keep theyaml.v2
option in use now). - Switch to another yaml library (may have to follow their format too), such as:
Metadata
Metadata
Assignees
Labels
No labels
Activity
Volte6 commentedon Mar 16, 2025
goccy looks promising.
I think we need to evaluate what effects this will have and what would need to be changed/updated.
Jasrags commentedon Apr 23, 2025
I’d suggest we use
yaml.v3
if it’s compatible with the functionality we need. I've been using it in a few projects without issue. While upstream maintenance is a concern, v3 currently seems stable enough for typical use cases.One way to future-proof ourselves would be to define an interface around our YAML functionality. This would allow us to isolate any future changes or library swaps behind a single implementation, making it easy to adapt if we decide to switch libraries later on.
Here’s a simple example of what that interface might look like:
lostsnow commentedon Apr 25, 2025
There is an additional problem, the formatting is not consistent from version to version or library to library, so the yaml files under
_datafiles
change a lot.Jasrags commentedon Apr 25, 2025
Given we have access to the current and new library it would not be too much effort to write a go program to read in and then rewrite the yaml files.
lostsnow commentedon Apr 25, 2025
go-yaml/yaml#865
Yes, rewrite the
Marshal()
function is a wayJasrags commentedon Apr 28, 2025
I'm going to start digging into this to see the level of effort to switch and expected changes.
Volte6 commentedon Apr 28, 2025
V3 is no longer maintained either.
https://github.com/go-yaml/yaml?tab=readme-ov-file#this-project-is-unmaintained
Jasrags commentedon Apr 28, 2025
Understood, will still dig into overall evaluation on what we should do going forward.
Jasrags commentedon Apr 28, 2025
Here are some benchmarks
Sample Struct (NOTE: sigs_k8s_io_yaml uses the json tag for yaml parsing)
BenchmarkMarshal
BenchmarkUnmarshal
Output files
test_goccy_go-yaml.yaml
test_sigs_k8s_io_yaml.yaml
test_yaml_v2.yaml
test_yaml_v3.yaml
test_yaml_output.zip
Jasrags commentedon Apr 28, 2025
Overall, I think a good next step would be to add the following interface and implementation of the v2 engine and move usage to that.
Volte6 commentedon Apr 28, 2025
We need to understand how this will affect current yaml usage, especially around struct tags:
Supported/Used tags:
Custom Tags:
Custom Marshal/Unmarshal
Also, how it will affect the requirements around how we layout the yaml - will the current yaml remain valid? Will it need to be mass-updated in some way? For example, are tabbing changes required? Do rules for 'empty' field detection change?
Jasrags commentedon Apr 28, 2025
I'll add those examples into the tests and add the results along with diffs, overall it seems like minor spacing changes on list items.
Jasrags commentedon Apr 28, 2025
diff --color data/test_yaml_v2.yaml data/test_goccy_go-yaml.yaml
diff --color data/test_yaml_v2.yaml data/test_sigs_k8s_io_yaml.yaml
diff --color data/test_yaml_v2.yaml data/test_yaml_v3.yaml
4 remaining items