The home of the CUE language! Validate and define text-based and dynamic configuration
This release includes a number of fixes and improvements for the experimental support for CUE modules first released in v0.8.0-alpha.1.
cue mod tidy gained a --check flag, which succeeds only if the module file contains exactly the required dependencies and also contains a canonical CUE language version.
cmd/cue and cue/load now send a detailed HTTP User-Agent string to CUE registries when sending HTTP requests, including the CUE and Go versions, rather than Go's default net/http user agent string.
cmd/cue now supports CUE_DEBUG=http to print HTTP logging information to stderr in JSON format.
Local builds of cmd/cue, such as running go install ./cmd/cue, now include a proper CUE version, allowing cue mod init and cue mod tidy to insert language.version as expected.
cue mod init modpath@version" by @mvdan in b1e40aefdbf240a3fc1d2cbe293dc78c37ded1f0This release includes a number of fixes and improvements for the experimental support for CUE modules first released in v0.8.0-alpha.1.
A new cue mod get command is added, which can add a new module dependency, update an existing one, or downgrade an existing one as long as it does not cause any conflict.
The cue/load package has a new Config.Env struct field to provide the environment variables used to load CUE modules from registries.
A new cue help registryconfig documentation section has been added, explaining how $CUE_REGISTRY works as well as the configuration file schema it supports.
This release includes a number of fixes and improvements for the experimental support for CUE modules first released in v0.8.0-alpha.1.
Thank you to @kharf, @mvdan, @myitcv, @nickfiggins, and @rogpeppe for contributing to this release!
The cue/load package now supports loading CUE instances using the CUE Modules experiment, which was first added to cmd/cue in v0.8.0-alpha.1.
cue/load supports the CUE Modules experiment out of the box with the environment variable CUE_EXPERIMENT=modules. Alternatively, a custom registry and authorizer can be configured with the Config.Registry field via the modconfig.NewRegistry API.
We have also added new Go examples to the cue/load package, including an example demonstrating the use of a CUE modules registry.
CL 1177330 fixes a bug where some evaluation errors in tools/flow and cue cmd were omitted, causing unintended results.
CL 1177546 tweaks cmd/cue so that it obeys the --package flag when the output format is CUE.
cue mod init modpath@version by @mvdan in 94a444fe9ce568e4e7e90f6aca142de605874b16This release includes a number of fixes and improvements for the experimental support for CUE modules first released in v0.8.0-alpha.1.
Note that we skipped over v0.8.0-alpha.2 due to a minor release automation issue.
CUE_REGISTRY now supports a CUE configuration file in addition to the simple string form, which allows greater control over how to publish CUE modules as artifacts on OCI registries. This is useful when publishing to OCI registries which do not support arbitrary repository names, for example. This is not fully documented yet, but the schema for the file is available here and setting CUE_REGISTRY=file:path/to/file enables its use.
All cue subcommands should now support the modules experiment when it is enabled via CUE_EXPERIMENT=modules.
cue mod init now adds the language.version field as needed, to ensure that running cue mod tidy immediately after results in no changes.
CUE_MODCACHE has been replaced with CUE_CACHE_DIR, a parent directory to hold all cache files, much like how CUE_CONFIG_DIR already works for configuration files.
cue mod registry, a hidden command to start a local in-memory OCI registry for testing purposes, now treats repository tags as immutable to ensure published module versions cannot be modified. The "Working with a custom module registry" tutorial has been updated to use cue mod registry.
This release includes the first version of an experimental Language Server Protocol (LSP) implementation for CUE. Whilst it remains experimental, the cmd/cuepls binary is separate from cmd/cue. However at a later date it will most likely to become a subcommand of cmd/cue like cue lsp serve.
We are working on updating the VSCode plugin to use cmd/cuepls, as well as supporting an initial version of a plugin for Neovim. For JetBrains users, we are working with the author of the CUE plugin to understand how best to integrate cmd/cuepls with JetBrains.
Subscribe to the LSP announce discussion, or join us in #cuepls on CUE Slack.
cue mod tidy to pass by @mvdan in bd966600bfc1a9fed729ee9bd2520a6bffe09047This release includes experimental support for CUE Modules (more details below), as well as a number of improvements and fixes.
More CLs and refactors have also landed for the core evaluator's performance work; they aren't enabled yet as the work isn't complete.
As a reminder: users can register their projects with Unity, our regression and performance testing setup. Unity is used to ensure that a project's CUE evaluations do not unexpectedly stop working, or regress in terms of performance. It continues to catch multiple issues with each release. Adding your project to Unity not only guarantees that we will not break your tests (if we do, we will work with you to fix your CUE code), but it also helps to improve the quality of each CUE release. Follow this link to learn more about Unity, install it, or get in touch with any questions.
Thank you to @4ad, @cedricgc, @jpluscplusm, @martingreber, @mpvl, @mvdan, @myitcv, @nickfiggins, @nnnkkk7, @rogpeppe, and @vikstrous for contributing to this release!
This release includes experimental support for CUE modules in cmd/cue, as outlined in the Modules and package management proposal. We are also working on v3 of the modules proposal docs to coincide with the release of v0.8.0.
Alongside this release, we have published a tutorial on the new website which shows how to publish and fetch modules with a custom module registry.
We have also published the first version of the Modules reference documentation, the canonical documentation page describing how CUE modules work in detail.
Note that support for CUE modules is still experimental and subject to change, and needs to be explicitly enabled via CUE_EXPERIMENT=modules. See cue help environment for more information on the environment variables used below.
The cue mod tidy command is introduced, which rewrites cue.mod/module.cue in its canonical format, adds any missing module dependency requirements, and removes unused ones.
The cue mod publish command is also added. This publishes a version of the current module to a module registry.
When running commands like cue export with CUE_EXPERIMENT=modules, dependencies are automatically fetched from module registries following $CUE_REGISTRY and cached on disk.
Note that support for fetching modules from OCI registries via cue/load isn't ready yet; support for Go library users will be announced at a later time.
Note that this version of CUE requires Go 1.21 or later, following our policy to support the latest two stable Go releases just like upstream.
CL 1173271 drops support for legacy pkg directories, which have been deprecated since the transition to a cue.mod directory in 2019.
CL 1174069 replaces a few more uses of the deprecated cue.Instance type with cue.InstanceOrValue.
CL 1175779 deprecates the FileOffset and File.Base APIs in cue/token, which were inherited from go/token but never had any effect.
There are no changes to the language in this version.
CL 1173197 makes the use of the term "builtin function" consistent across the document.
CL 1173262 fixed a regression introduced by v0.7.0's upgrade to github.com/cockroachdb/apd/v3 where some arithmetic operations would result in an extra 0 digit.
CL 1173689 fixed the YAML encoder so that strings looking like hexadecimal numbers are properly quoted.
CL 1173735 replaces the uses of Go's net package with net/netip when dealing with IP addresses, which makes them immutable, comparable, and take less memory.
CL 1173926 adds an IPv6 API to net to check that a value is a valid IPv6 address, mirroring IPv4 and taking advantage of the switch to the Go net/netip package.
CL 1174339 fixes tool/exec so that it correctly applies env defaults in CUE values.
CL 1174623 fixes tool/exec so that it accepts env list values as documented.
cmd/cueCL 1173892 adds a cue help environment section to document the environment variables used by the CLI, such as CUE_EXPERIMENT and CUE_REGISTRY.
CL 1176665 fixes cue cmd so that legacy commands always get the corresponding CUE schema unified.
CL 1176194 starts adding a language.version field to cue.mod/module.cue, to start tracking what CUE language version a module's config files were written for. This will become necessary to make future language changes as smooth as possible for CUE users. For example, running cue mod init or cue mod tidy with the future CUE v0.8.0 release should add language: version: "v0.8.0" when the field isn't present.
cue mod publish by @mvdan in 2930a8ea50835be296fadcf12493552f03cb38cbcue mod tidy by @mvdan in 34db9eb3f3109337b860f497f5d48374f5aac807cue mod init modpath@version by @mvdan in 7855e15cb70165ba9b09d6c654fb90aa2a12a082This release is a re-build of CUE v0.7.0 with Go 1.22.0 to prevent cue get go panics; see https://github.com/cue-lang/cue/issues/2802.
This release comprises a number of bug fixes and small improvements, as well as more ground work for Modules, WebAssembly, and the core evaluator's performance refactors.
Note that v0.7 was originally planned to center around the core evaluator's performance improvements. Since those refactors are not ready, and we have other fixes and improvements we want to release, we have slightly altered the release plan accordingly. We will share more details on our next community call.
As a reminder: users can register their projects with Unity, our regression and performance testing setup. Unity is used to ensure that a project's CUE evaluations do not unexpectedly stop working, or regress in terms of performance. Unity continues to catch multiple issues with each release. Adding your project to Unity not only guarantees that we will not break your tests (if we do, we will work with you to fix your CUE code), but it also helps to improve the quality of each CUE release. Follow this link to learn more about Unity, install it, or get in touch with any questions.
Thank you to @SteVwonder, @bozaro, @cedricgc, @howardjohn, @mpvl, @mvdan, @myitcv, @nickfiggins, @rogpeppe, @rudifa, and @uhthomas for contributing to this release!
And a special thanks to all who joined the recent contributor office hours calls on our community calendar, as well as our #contributing channel on Slack! Thanks to their involvement, more issues can be investigated and fixed each release.
Note that this version of CUE requires Go 1.20 or later, per our policy to support the latest two stable Go releases just like upstream.
CL 1172105 fixes a regression introduced in v0.6.0 where calling Iterator.Selector.Index while iterating over a list would incorrectly panic.
CL 1167597 fixes cue/load so it now errors on package import cycles, following the spec.
CL 1167647 adjusts cue.Value.Decode to decode empty CUE lists into a Go interface{} as a non-nil empty slice.
CL 547369 teaches cue.Value.Decode how to decode values which aren't entirely concrete into a Go type by using cue.Value as part of the destination type.
There are no changes to the language in this version.
CL 1171216 fixes two errors in a dynamic fields example.
CL 1172014 disallows the direct use of unary operators with basic types, since they would result in confusing bounds which seemed incorrect.
CL 1172013 fixes a closedness bug where close did not properly apply when used inside definitions.
CL 1172874 fixes a panic in cue export introduced by v0.6.0.
CL 1172314 teaches encoding/protobuf to follow the field_behavior annotation marking a field as either optional or required when decoding.
CL 1172991 adds a mustSucceed boolean parameter to tool/exec.Run, which can be set to false to allow a command to fail and set its own field success to false.
CL 557322 fixes the values of math's Log2E and Log10E constants, which were being incorrectly truncated.
cmd/cueCLs 1170966 and 1171302 fix a number of issues in cue fmt (and by extension the cue/format package), resulting in better and more consistent formatting of CUE files.
CLs 1171292, 1171015, 1170115, and 1171971 implement a variety of improvements and bug fixes for cue get go.
CL 1172017 fixes a number of issues with the line and column positions reported by our YAML decoder, which could result in weird CUE formatting when using cue import or misleading positions being shown to the user.
CL 1169709 increases the robustness of cue export -o, which in some situations could ignore file errors or incorrectly replace an existing file without the -f flag.
CL 1173072 fixes a panic when using cue import --list with empty YAML input.
CL 1168436 updates the cue export documentation to add the missing cue and binary supported export formats.
A number of changes are included to support an experimental implementation of the proposed modules and package management support. These aren't enabled by default, and will be announced soon.
go test -race by @mvdan in cbdd996110a9c9068cde7187ddd09744efeb138aThis release comprises a number of bug fixes and small improvements, as well as more ground work for Modules, WebAssembly, and the core evaluator's performance refactors.
Note that v0.7 was originally planned to center around the core evaluator's performance improvements. Since those refactors are not ready, and we have other fixes and improvements we want to release, we have slightly altered the release plan accordingly. We will share more details on our next community call.
As a reminder: users can register their projects with unity, our regression and performance testing setup. unity is used to ensure that a project's CUE evaluations do not unexpectedly stop working, or regress in terms of performance. unity continues to catch multiple issues with each release. Adding your project to unity not only guarantees that we will not break your tests (if we do, we will work with you to fix your CUE code), but it also helps to improve the quality of each CUE release. Follow this link to learn more about Unity, install it, or get in touch with any questions.
Thank you to @SteVwonder, @bozaro, @cedricgc, @howardjohn, @mpvl, @mvdan, @myitcv, @nickfiggins, @rogpeppe, @rudifa, and @uhthomas for contributing to this release!
And a special thanks to all who joined the recent contributor office hours calls on our community calendar, as well as our #contributing channel on Slack! Thanks to their involvement, more issues can be investigated and fixed each release.
Note that this version of CUE requires Go 1.20 or later, per our policy to support the latest two stable Go releases just like upstream.
CL 1172105 fixes a regression introduced in v0.6.0 where calling Iterator.Selector.Index while iterating over a list would incorrectly panic.
CL 1167597 fixes cue/load so it now errors on package import cycles, following the spec.
CL 1167647 adjusts cue.Value.Decode to decode empty CUE lists into a Go interface{} as a non-nil empty slice.
CL 547369 teaches cue.Value.Decode how to decode values which aren't entirely concrete into a Go type by using cue.Value as part of the destination type.
There are no changes to the language in this version.
CL 1171216 fixes two errors in a dynamic fields example.
CL 1172014 disallows the direct use of unary operators with basic types, since they would result in confusing bounds which seemed incorrect.
CL 1172013 fixes a closedness bug where close did not properly apply when used inside definitions.
CL 1172874 fixes a panic in cue export introduced by v0.6.0.
CL 1172314 teaches encoding/protobuf to follow the field_behavior annotation marking a field as either optional or required when decoding.
CL 1172991 adds a mustSucceed boolean parameter to tool/exec.Run, which can be set to false to allow a command to fail and set its own field success to false.
CL 557322 fixes the values of math's Log2E and Log10E constants, which were being incorrectly truncated.
cmd/cueCLs 1170966 and 1171302 fix a number of issues in cue fmt (and by extension the cue/format package), resulting in better and more consistent formatting of CUE files.
CLs 1171292, 1171015, 1170115, and 1171971 implement a variety of improvements and bug fixes for cue get go.
CL 1172017 fixes a number of issues with the line and column positions reported by our YAML decoder, which could result in weird CUE formatting when using cue import or misleading positions being shown to the user.
CL 1169709 increases the robustness of cue export -o, which in some situations could ignore file errors or incorrectly replace an existing file without the -f flag.
CL 1173072 fixes a panic when using cue import --list with empty YAML input.
CL 1168436 updates the cue export documentation to add the missing cue and binary supported export formats.
A number of changes are included to support an experimental implementation of the proposed modules and package management support. These aren't enabled by default, and will be announced soon.
go test -race by @mvdan in cbdd996110a9c9068cde7187ddd09744efeb138aThe main focus of this release is the introduction of required fields, as well as fixing a number of issues and regressions introduced in the v0.5.0 release.
As a reminder: users can register their projects with unity, our regression and performance testing setup. unity is used to ensure that a project's CUE evaluations do not unexpectedly stop working, or regress in terms of performance. unity continues to catch multiple issues with each release. Adding your project to unity not only guarantees that we will not break your tests (if we do, we will work with you to fix your CUE code), but it also helps to improve the quality of each CUE release. Follow this link to learn more about Unity, install it, or get in touch with any questions.
Thank you to @4ad, @Abirdcfly, @alexandear, @chee-zaram, @eraserhd, @ghostwheel42, @joanlopez, @jpluscplusm, @kcburge, @mpvl, @mvdan, @myitcv, @rogpeppe, @toshi0607, and @zeithaste for contributing to this release!
CL 543335 adds arch to set of injectable system variables understood by cue/load. The text at cue help injection explains how this in more detail.
CL 552142 adds support for zero values in cue.Value.Float64, which has the effect of fixing the error when attempting to use strconv.FormatFloat with a zero value.
CL 548783 fixes a long-standing bug to make HTML escaping in JSON an opt-in. This means that cue export now respects the --escape flag when set, and encoding/json only escapes HTML when HTMLEscape is used.
The main focus of the v0.6.0 release is the introduction of required fields.
CUE already supports the “optional field constraint”, denoted foo?: value.
Required fields add a “required field constraint”, denoted foo!: value, which is like foo?: value, but requires a regular field be provided for foo (a field foo: without !: or ?:).
We refer to optional field constraints and required field constraints collectively as “field constraints”.
As a general rule, all data and data templating should be defined with regular fields, whereas schemas would be defined in terms of field constraints. Of course, CUE being CUE, mixing these two fields is allowed: this rule is not a restriction but suggested as a matter of style and proper usage.
Here are some examples of how exclamation marks can be used to express things that were previously not possible.
#Def: {
kind!: "def"
intList!: [...int]
}
Using required fields can also result in better error messages. Consider this schema:
#Person: {
name: string
age?: int
}
Note that this is non-idiomatic, because our new guidelines suggest schemas should only be defined in terms of field constraints, but we will use this for illustration purposes.
Now consider this usage of #Person:
jack: #Person & {age: 3}
In data mode, the error message here is currently jack.name: incomplete value string, which does not provide much actionable information to the user to help them fix the problem.
Now consider how #Person looks with required fields, idiomatically only using field constraints:
#Person: {
name!: string
age?: int
}
jack: #Person & {age: 3}
Now the error message reads:
jack.name: field is required but not present
which more closely reflects the underlying problem..
This error could be resolved by adding jack: name: "Jack".
For more details and background on the change, please see the original required fields proposal.
Whilst it should not be a breaking change from a CUE perspective, we have upgraded to use github.com/cockroachdb/apd/v3. We have also increased apd.Context precision from 24 to 34.
CL 551207 adds support for making dynamic fields optional or required. For example, the following is now possible:
x: "y"
(x): "foo"
(x)?: "foo"
(x)!: "foo"
and yields:
x: "y"
y: "foo"
CL 546886 removes support for old-style :: definitions. This also includes deprecation support. In a similar vein, CL 547011 removes the last vestiges of <foo>: T. This was once the notation for pattern constraints.
Various bug fixes, with special thanks to @nicuveo for raising many of these.
The following four functions have been added to the net package:
PathEscape
PathUnescape
QueryEscape
QueryUnescape
Thanks to @eraserhd for this change.
CL 549087 reimplements pkg/list.Sort. The resulting reduction in the number of allocations and other work gives rise to a ~80% reduction in running time against CUE benchmarks.
cmd/cueCL 547212 improves the documentation for the -l flag passed to cue import. This addresses a frequent point of confusion in questions to GitHub Discussions and on Slack.
CL 550616 fixes cue get go to respect the --exclude flag for constants. This makes it possible to (for example) exclude all unexported identifiers from a cue get go run.
CL 555576 fixed an important bug where cmd/cue vet was not properly consuming all input data.
CL 556526 fixed a bug where CUE files beginning with an underscore were not being loaded when explicitly given as filename arguments.
We have added preliminary support for Wasm. Users can compile code from any language and toolchain that supports Wasm into plugins that are dynamically loaded by CUE. Users can then call and use functions from these Wasm modules, just like they can use standard library functions.
See the documentation at cuelang.org/go/cue/interpreter/wasm to learn more about Wasm and its current limitations.
cue help by @mvdan in 143b102b4fbcf3331c6f21f4222d59b06d41b270arch to set of injectable system variables by @jpluscplusm in 752b8e4a3f019d36440bb85445df69fbec209b09go install long tests by @mvdan in fa1f369cd616d9da12f110ee08f986b36e104730Thank you to @mpvl, and @mvdan for contributing to this release!