KYAML output format

[mxey]

Is your feature request related to a problem? Please describe.
The Kubernetes project has introduced KYAML as an output format. It is not really a new format, but rather a YAML subset that makes it look like JSON with comments.

There is a chance that this becomes the dominant formatting of YAML in Kubernetes contexts.

Describe the solution you'd like

Add KYAML as a format to CUE, as "-o kyaml" and and as CUE functions. This would make the output of CUE seem more natural and IMO it's just a more readable format.

Describe alternatives you've considered

Keep using YAML output: any Kubernetes YAML parser will continue to accept this, but using KYAML might feel more natural

Send the output of CUE through a KYAML formatter: an annoying extra step.

JSON output: JSON does not support multiple documents in a file, which makes it harder to feed into kubectl apply.

Change CUE's YAML output to be KYAML: since KYAML is totally valid YAML, that would be “legal” but not what people expect when they ask for YAML, most likely.

Add KYAML formatting as some kind of flag to the YAML output?

Additional context

KEP-5295: Introducing KYAML, a safer, less ambiguous YAML subset / encoding

https://github.com/google/yamlfmt supports KYAML formatting.

[mvdan]

It looks like Kubernetes has implemented KYAML as an internal module which is not really intended for external use: https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml

Moreover, this seems to be a full YAML implementation, possibly a fork of an existing YAML library like go-yaml. That's not a good option for us, because depending on two YAML libraries will increase build sizes and cause weird inconsistencies for end users.

So I think the only viable solution is for a mainstream YAML library to add support for encoding as KYAML. Support on the encoder side seems enough, given that KYAML is a strict subset of YAML. For example: goccy/go-yaml#863

Aside from the technical points above, I don't have a strong feeling about this feature request. It seems reasonable assuming that KYAML will likely become pretty common in the Kubernetes ecosystem. Even though this issue is not strictly needed for compatibility, I agree that it's nice to be able to emit the same encoding that the rest of the ecosystem is now encouraging.

[mxey]

It looks like Kubernetes has implemented KYAML as an internal module which is not really intended for external use: https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml

@mvdan No, that is something else:

// Package kyaml contains libraries for reading and writing Kubernetes Resource configuration
// as yaml.

sigs.k8s.io/yaml/kyaml is a public package for KYAML. That's what yamlfmt uses. It's built on go.yaml.in/yaml/v3, which seems to be the same module that CUE uses.

[mvdan]

OK, thanks, so there is indeed a library.

It looks like it's not a fork, but then what it does is to do an expensive post-process step. So a single KYAML encode would be a marshal, unmarshal, and then re-marshal again. So my preference is still for a mainstream YAML library to add direct support for this.

[mxey]

So a single KYAML encode would be a marshal, unmarshal, and then re-marshal again.

Yeah, it even initially marshals as JSON, not as YAML, similar to how YAML is generally used in Kubernetes to avoid some type issues.

	// Convert the object to JSON bytes to take advantage of all the JSON tag
	// handling and things like that.
	jb, err := json.Marshal(obj)
	if err != nil {
		return nil, fmt.Errorf("error marshaling to JSON: %v", err)
	}

So this might be more of a result of keeping that special JSON-based handling, and not a necessity for the format. I assume a lot of it can be achieved by setting the right formatting flags in a YAML library 🤔

[mvdan]

Maybe. That could be a core Kubernetes requirement that they can't untangle now. Regardless, it's not something that we want to adopt ourselves.