-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade yaml.v2 to yaml.v3, improve testing and bugfixes #61
Conversation
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Welcome @inteon! |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: inteon The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I think @liggitt is a better person to ask. |
Discussing with @inteon on the Kubernetes slack now (https://kubernetes.slack.com/archives/C0EG7JC6T/p1631778930193700?thread_ts=1631728530.180800&cid=C0EG7JC6T); there is a need to redesign this library more or less completely in a spec-driven way, i.e. write a KEP for what a v2 of this library should look like. Furthermore, to be consistent with the k8s API machinery, we also need to depend on the same JSON logic from here https://github.com/kubernetes/apimachinery/blob/master/pkg/runtime/serializer/json/json.go#L113-L184, and hence I think creating a This again ( I have listed some issues needing resolution in https://github.com/luxas/deklarative/issues (a PoC/MVP repo for this kind of work), have some PoC work of what sigs.k8s.io/yaml v2 could look like in luxas/deklarative#8, and have identified some upstream issues that need fixing in https://github.com/json-iterator/go/issues. But there's more to this. From the top of my head, these are the specifications:
We need to make sure we agree on a specific subset of the YAML + JSON union that is considered "supported" for Kubernetes, and what is out of scope. |
kubernetes/kubernetes#105030 Is relevant to the json bits. It's more driven by an immediate desire to drop json-iterator because of correctness and compatibility reasons. |
Oh, wow, I had no idea that was going on, thanks for the heads up @liggitt, will definitely take a look 👍! |
That PR is heavily oriented toward:
|
A heads-up that https://github.com/kubernetes-sigs/json is now available to use (thanks @liggitt!!) It satisfies the above criteria as it:
Meanwhile, k8s has moved on to using @inteon would you be up for rebasing this PR to use this new json library? |
/uncc |
@luxas I updated the PR, so it now uses the new json library! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's a lot of changes going on here that make this a bit hard to review as a piece... is it possible to do each of the following independently:
- use
sigs.k8s.io/json
- switch to yaml.v3
- make additions to the surface area exposed by this library to add new features
@liggitt thanks for the first review, I made some additional changes based on your feedback. Next step will be to split this PR into multiple smaller PRs. Feel free to provide additional feedback. I'll let you know once I've split this PR into multiple smaller PRs, but this might take some time as I'm quite busy right now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @inteon for your great work 🥇 💯!
This is not a very straightforward change; it needs to be reasoned about quite deeply. I have added some comments on areas where we should still decide a way forward, but it probably requires some kind of broader SIG API Machinery and kyaml review and approval.
I don't really know if I've got the time to write a KEP around this right now, but it'd be great to formalize these things. Meanwhile, maybe we can discuss where we want to go in this PR?
cc @laverya @fejta @sttts @neolit123 @dims from #26. As pointed out by @inteon in #26 (comment):
it hasn't been released yet, however, I guess it'll come in a |
84a7f62
to
34069b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for rebasing and upgrading! This starts looking really good 🤩
btw, was there a reason for dropping earlier versions of Go in the CI?
yaml.go
Outdated
if jsonTarget.Kind() != reflect.Ptr || jsonTarget.IsNil() { | ||
return nil, fmt.Errorf("provided object is not a valid pointer") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was the remove / addition of this code snippet intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding this check should be a solution for #30
@@ -336,7 +348,7 @@ func convertToJSONableObject(yamlObj interface{}, jsonTarget *reflect.Value) (in | |||
case int64: | |||
s = strconv.FormatInt(typedVal, 10) | |||
case float64: | |||
s = strconv.FormatFloat(typedVal, 'g', -1, 32) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this need to merge to the current master branch too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a reference to float32 vs float64 (go-yaml/yaml#83) in the original code.
"strconv" | ||
"testing" | ||
|
||
"github.com/davecgh/go-spew/spew" | ||
yaml "gopkg.in/yaml.v2" | ||
) | ||
|
||
/* Test helper functions */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the JSONToYAML and Marshal tests I would expect the sequence indentation style to have changed to wide instead of compact, due to an upstream change. Is that true? As discussed earlier, kustomize carries a fork of go-yaml for that reason, to provide customizability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That upstream change blocks migration to yaml.v3. We don't want any externally visible change in serialization behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the information, I'll probably create a fork of go-yaml in this repo too & create an upstream PR (if no PR is present yet).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we're open to forking the yaml repo at this point. The kustomize fork is intended to be temporary and they are pursuing options to bring the V3 library back into a compatible state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fixes kustomize needs to land in yaml.v3 to restore compatibility are either in go-yaml/yaml#756 or go-yaml/yaml#753
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but can't we add a temporary fork here too? Seems like the kyaml team has been trying for a long time to get this option added. Would be great if we could not block this PR until upstream has fixed the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, it's not urgent enough to move off yaml.v2 to take on the added uncertainty / maintenance cost of a fork
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we could use yaml.v3 for unmarshalling and yaml.v2 for marshalling; that would fix all problems, only downside is having 2 deps
… fields.go & update interface
Thanks for the review; looks like we're getting close to the "ideal" solution. PS: the reason I removed the tests for go-versions below 1.17, is because |
@inteon: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Any updates on this? My team needs a fix for #58 :( |
@inteon doesn't look like there is a possibility of this landing given the time and the situation has not changed ( #61 (comment) ) |
fixes: #58
fixes: #47
fixes: #45
fixes: #18
Thorough refactor of this repo, improves tests & tries to solve the most common problems (by upgrading to yaml.v3 and fixing some bugs).
JSONObjectToYAMLObject
was removed, but this function does not seem to be used a lot (please correct me if I'm wrong).This might have to be release as v2 of this go library.