cmd/cue: add diff support

[mpvl]

Allow diffing between (snapshots of) previous version and current version.

[jugaadi]

Any updates on this feature?

[mpvl]

It would be good for people to give examples of how they would like to use this functionality in a CLI.
There is an internal package for diffing CUE, which could potentially also be exposed as a Go API.

[myitcv]

Commenting simply to add the word semantic into the mix 😄

I've taken (perhaps incorrectly) to referring to cue diff as a semantic diff, distinct from cmp and friends ("plain diff") used in unity.

[eonpatapon]

Would be nice to have a diff API in cue lib. Currently I'm using Value.Decode and https://github.com/r3labs/diff to diff two cue instances in order to detect which part of the configuration has changed (based on this CI jobs are run).

However this works if the instances have only concrete values. So a similar API that can diff cue values directly would be nice (and required in my case to be able to use the flow API)

[myitcv]

@eonpatapon take a look at https://pkg.go.dev/cuelang.org/[email protected]/internal/diff. That is internal for now, but as we shape up the API it should be made non-internal.

[vikstrous2]

A semantic diff would be really interesting. I think with diffing kubernetes files, the most awkward part is the way that the kubernetes API wants to be given a list of yaml objects but the identity of those objects is usually best defined by their name rather than their position in a list. My current idea for diffing them is to write them out into a directory tree where the name of the file is based on the name and type of the object and then using git diff. Then as long as the yaml and all of its fields and lists of named objects are sorted in some stable way, this is good enough for most kubernetes things.

[myitcv]

Adding something of an experience report here from the world of unity.

unity tests (of cmd/cue) generally follow this rough pattern:

1. Ensure that evaluation of a given configuration semantically matches expectations. This is, in effect, a CUE semantic diff
2. Verify that output in a specific format (JSON, Yaml, etc) matches expectations. This is, in effect, a semantic diff in the output format

In the case of point one this will look like:

# CUE semantic diff
cue eval -o out.cue X
cue diff out.cue ref.cue

# JSON diff
cue eval -o out.json X
cue diff out.json ref.json

Some questions:

• Is cue eval the right command here? cue eval will become cue - but does that give the intended result, as far as concreteness etc are concerned?
• file.ref will need to be a complete, self-contained configuration. This might well require it to be a txtar archive?

Stepping back a bit further, we should also be able to write a semantic diff for point 2, on the basis that CUE knows about the semantics of these different formats (even to some extent the different versions of, say, Yaml, JSON).

[cueckoo]

This issue has been migrated to cue-lang/cue#8.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.