cmd/cue/cmd: add go tag for or expressions

[LucasLundJensen]

This adds a new Go tag which allows the use of OR expressions when generating Cue based on Go.

I'm aware that this change might not be the desired way of resolving the lack of having OR expressions available based on tags in cue tags in Go structs. If that is the case, take this PR as more of a discussion on how to properly implement this.

I've got the need for this feature, as it'll allow me and my team to generate CUE schemas purely based on our Go structs with the desired defaults that we intend to have on those fields. A more concrete example is the following:

type Module struct {
	Org string `json:"org,omitempty" yaml:"org,omitempty" cue_or:"*\"org_name\""`
}

#Module: {
	org?: string | *"org_name" @go(Org)
}

Where as the only tag available today cue only supports AND expressions.

[mvdan]

Our thinking in this space is to provide the opposite of cue get go, so that you can define your schemas in CUE as the source of truth, and generate Go types which approximate the shapes well enough so that you can decode CUE values into Go.

This is ultimately the most flexible approach, as you can define as many constraints on the CUE side as you want, without having to somehow fit everything into Go struct field tags. We also find that to be more consistent, because we tend to want to write CUE validation and other logic alongside the schema definition, so it's a bit odd if the schema's source of truth is in a Go file separate from the rest of the CUE.

I'm currently working on this as we need it ourselves - the first version will be experimental and fairly simple, but I believe we can extend it to support most use cases.

[mvdan]

And I forgot to say - thank you for contributing!

[LucasLundJensen]

Our thinking in this space is to provide the opposite of cue get go, so that you can define your schemas in CUE as the source of truth, and generate Go types which approximate the shapes well enough so that you can decode CUE values into Go.

This is ultimately the most flexible approach, as you can define as many constraints on the CUE side as you want, without having to somehow fit everything into Go struct field tags. We also find that to be more consistent, because we tend to want to write CUE validation and other logic alongside the schema definition, so it's a bit odd if the schema's source of truth is in a Go file separate from the rest of the CUE.

I'm currently working on this as we need it ourselves - the first version will be experimental and fairly simple, but I believe we can extend it to support most use cases.

This is exactly the route we wanted to go in the first place, but realized that it wasn't entirely possible yet. Hence why this is our approach currently, but we'd be excited to switch over to having CUE be our source of truth later on.

[mvdan]

https://github.com/cue-lang/cue/releases/tag/v0.12.0-alpha.2 was just released with the generation of Go types from CUE definitions as cue exp gengotypes :) Please let me know how you get on with it. In the meantime, I think it makes sense to close this pull request, as we are in agreement that CUE as the source of truth is the better method going forward. We have also transitioned away from cue get go in a few of our own use cases.

[mvdan]

Closing for now per the above, but please feel free to reach out if you have any questions. I'm "mvdan" on both our Discord and Slack as well. We plan to write a brief tutorial for cue exp gengotypes on the website soon as well.