Comments (14)
@vikstrous2 @PierreR I've used https://github.com/homeport/dyff for creating diffs of outputs from CUE for CloudFormation. Quite nice. Works really well for semantic diffs. Worth a look! And, hopefully we can build something similar for CUE at some point. :)
from cue.
Original reply by @jugaadi in cuelang/cue#8 (comment)
Any updates on this feature?
from cue.
Original reply by @mpvl in cuelang/cue#8 (comment)
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.
from cue.
Original reply by @myitcv in cuelang/cue#8 (comment)
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
.
from cue.
Original reply by @eonpatapon in cuelang/cue#8 (comment)
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)
from cue.
Original reply by @myitcv in cuelang/cue#8 (comment)
@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.
from cue.
Original reply by @vikstrous2 in cuelang/cue#8 (comment)
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.
from cue.
Original reply by @myitcv in cuelang/cue#8 (comment)
Adding something of an experience report here from the world of unity
.
unity
tests (of cmd/cue
) generally follow this rough pattern:
- Ensure that evaluation of a given configuration semantically matches expectations. This is, in effect, a CUE semantic diff
- 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 becomecue
- 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).
from cue.
In the case of generating kubernetes configs, we use a _tool.cue file to write out the config to many different yaml files. Those files can be individually diff'd by git diff. A fancier diffing algorithm would probably just do some sorting and normalization before diffing, which would bring it pretty close to a semantic diff. There isn't anything really cue specific needed for that.
If cue eval is used for diffing, it might produce unusual looking output if most users of the cue config usually interact with it through a _tool.cue command.
A diff of cue configs is interesting, but it seems like a very open ended topic. I think my understanding of CUE is not sufficient to have an opinion on how that should work.
from cue.
FWIW what we are currently doing is output the result of cue eval
that we then sorts with jq.
That's less than optimal (!) and a proper semantic diff would be much appreciated.
from cue.
And, hopefully we can build something similar for CUE at some point. :)
The query extension offers some nice potential for good semantic diff output.
from cue.
A sub-feature-request: allow the user to specify if/that certain lists' contents can be treated as being identical based on member contents, not ordering. In other words (I /think/): to mark specific lists as sets, not lists, for diff purposes.
Rationale: field ordering in a struct is always(?) semantically unimportant. Ordering in a list is /sometimes/ unimportant, but it's case-specific. The cue diff
feature would be valuable to a wider set of users if there were the ability to mark/configure (at diff
time) which lists' contents were, essentially, order-agnostic.
Example: I'm currently using CUE to emit GitHub Actions (GHA) workflow .yml files, and I needed to assert that a specific commit had only reorganised the input CUE, and hadn't change the output .yml. One list in my workflow file is "the jobs to run". Obviously, order is important there. But there's a job at the /end/ of the workflow, which waits for all other jobs, and reports if all jobs succeeded. This final job's input is a list of job names, but it doesn't care about the order, merely that they're present. Being able to cue diff
the input CUE, and not rely on git diff
of the output yaml, would have been useful; even moreso if I could have taught the diff
invocation to ignore ordering changes to the final job's input list.
from cue.
In other words (I /think/): to mark specific lists as sets, not lists, for diff purposes.
Having been kindly pointed towards #14 and onwards to #165 (comment), I can amend my sub-request to be: please could diff
be capable of being associative-list aware, with the ability to (if not the default behaviour of) ignoring purely order-based changes in associative lists. TVM!
from cue.
As part of the recent issue garden, we are focussing on non-feature requests. As such, I'm removing the milestone on this feature request. We will revisit feature requests in a later pass, at which point we will start to milestone and prioritise new features (in addition to those that we are already working on).
from cue.
Related Issues (20)
- internal/mod/modregistry: some registries do not support arbitrary repo names
- internal/mod/modregistry: gitlab registry does not support modules artifact type HOT 5
- alpha.cuelang.org: add support for sudo commands in multi-step scripts
- cmd/cuepls: port version logic from cmd/cue
- cmd/cue: tool files do not support modules
- cmd/cue: mod registry allows the same version of a module to be uploaded twice
- alpha.cuelang.org: integrations need a refresh
- alpha.cuelang.org: version number missing from docs HOT 1
- alpha.cuelang.org: support getting canonical URL for a page
- alpha.cuelang.org: front matter for a page should be CUE HOT 1
- alpha.cuelang.org: a page with errors is never "seen" in serve mode
- alpha.cuelang.org: serve.bash reports slow consumer HOT 1
- cmd/cue: verify that all commands know about modules
- cmd/cue: add mod where (or similar) command
- cmd/cue: help environment docs do not specify how CUE_REGISTRY prefix is matched
- alpha.cuelang.org: use a shared Go cache for multi-step bash scripts HOT 1
- cmd/cue: help environment docs do not mention CUE_STATS_FILE HOT 3
- cmd/cue: use CUE_CACHE_DIR instead of CUE_MODCACHE
- project: pre-commit hooks HOT 8
- Accessing fields of embedded defnition HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cue.