| commit | 21ca371cabde8486aa23c746fcc859a18f68f4bc | [log] [tgz] |
|---|---|---|
| author | Marcel van Lohuizen <mpvl@golang.org> | Thu Jun 04 11:59:12 2020 +0200 |
| committer | Marcel van Lohuizen <mpvl@golang.org> | Fri Jul 03 12:19:51 2020 +0000 |
| tree | c044d191428b037a30c7bf7dd6c8a69827593ca0 | |
| parent | a20e1d407e48b60e95f77c9f4dea45d7486d0109 [diff] |
doc/ref/spec.md: alternative definitions for closedness and friends This CL changes the meaning of `[x]: y` and `...` fields and closedness with the following objectives: - Incorporate experience of usability of defintions and closedness - Simplify the rules of closedness to simplifiy both its usages and implementation - Make it (far) easier to express JSON Schema in CUE. - Allow closedness to be expressed in terms of CUE itself The expressability of JSON Schema in CUE seems important as this seems to becoming one of the major application domains of CUE. Aside from that, it is a general win for the language as it results in more expressability without loss of generality: the old CUE semantics can easily be simulated by enclosing bulk optional fields in curly braces (the current `cue fmt` and `cue fix` currently do this rewrite). The changes to bulk optional fields (now pattern constraints) bring them in line with the definition of "patternProperties" of JSON Schema. The same holds for the `...` notation, which now maps to additional properties. To allow for a complete one-to-one mapping, the spec now also allows for `...T`. This brings it in line with the semantics for lists. Coincidentally, the new JSON Schema semantics allows closed structs to be defined in terms of CUE itself (using `..._|_`). In addition, the new simplified definition aims to simplify implementation and incorporate user feedback to make definitions and closed structs more intuitive. As a consequence of the simplified defintions, let expressions can no longer be used to circumvent closedness. The relaxed rules around closedness and the earlier reintroduction of hidden fields make this an acceptable compromise. Transition plan: The new definition changes the meaning of existing syntax. The plan is to first rewrite the old semantics into equivalent CUE that will give the same results with the new interpretation. This is already implemented with cue fix and cue fmt. The next step is to prohibit any usage of bulk optional fields that will mean something different with the new syntax (CL pending). Finally, the new behavior is implemented by the new evaluator. Change-Id: I2617597ea4a973d8987239ead4e62d51002c622b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6260 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Configure, Unify, Execute
CUE is an open source data constraint language which aims to simplify tasks involving defining and using data.
It is a superset of JSON, allowing users familiar with JSON to get started quickly.
You can use CUE to
CUE merges the notion of schema and data. The same CUE definition can simultaneously be used for validating data and act as a template to reduce boilerplate. Schema definition is enriched with fine-grained value definitions and default values. At the same time, data can be simplified by removing values implied by such detailed definitions. The merging of these two concepts enables many tasks to be handled in a principled way.
Constraints provide a simple and well-defined, yet powerful, alternative to inheritance, a common source of complexity with configuration languages.
The CUE scripting layer defines declarative scripting, expressed in CUE, on top of data. This solves three problems: working around the closedness of CUE definitions (we say CUE is hermetic), providing an easy way to share common scripts and workflows for using data, and giving CUE the knowledge of how data is used to optimize validation.
There are many tools that interpret data or use a specialized language for a specific domain (Kustomize, Ksonnet). This solves dealing with data on one level, but the problem it solves may repeat itself at a higher level when integrating other systems in a workflow. CUE scripting is generic and allows users to define any workflow.
CUE is designed for automation. Some aspects of this are:
Using Homebrew, you can install using the CUE Homebrew tap:
brew install cuelang/tap/cue
If you already have Go installed, the short version is:
go get -u cuelang.org/go/cmd/cue
This will install the cue command line tool.
For more details see Installing CUE.
The fastest way to learn the basics is to follow the tutorial on basic language constructs.
A more elaborate tutorial demonstrating of how to convert and restructure an existing set of Kubernetes configurations is available in written form.
Language Specification: official CUE Language specification.
API: the API on godoc.org
Builtin packages: builtins available from CUE programs
cue Command line reference: the cue command
Our canonical Git repository is located at https://cue.googlesource.com.
To contribute, please read the Contribution Guide.
To report issues or make a feature request, use the issue tracker.
Changes can be contributed using Gerrit or Github pull requests.
You can get in touch with the cuelang community in the following ways:
Unless otherwise noted, the CUE source files are distributed under the Apache 2.0 license found in the LICENSE file.
This is not an officially supported Google product.