| commit | a6169255715d7fcd71ab70ac53902be22df5f2a0 | [log] [tgz] |
|---|---|---|
| author | Paul Jolly <paul@myitcv.io> | Tue Dec 29 22:41:11 2020 -0500 |
| committer | Paul Jolly <paul@myitcv.org.uk> | Fri Jan 29 15:29:20 2021 +0000 |
| tree | 83e58bd63c2ef84ce4f240ac6b94894d4d956be1 | |
| parent | dfce25c5ebaa99db30edb3f55c96e9c19c9e3cd7 [diff] |
cmd/cue: embed packages required for get go checking
Currently, 'cue get go' loads interface types from
cmd/cue/cmd/interfaces during initialisation. Go types that satisfy
these interface types are then used as special cases for the target CUE
definition types - see the complete logic in (*extractor).altType.
Given the nature of 'cue get go' (i.e. that we are looking to import CUE
definitions from Go code), it is assumed that the command will be run in
the context of a main Go module. That is to say, 'go env GOMOD' will be
non-empty. The package arguments to 'cue get go' (and their
dependencies) will be resolved via the main Go module.
Currently, 'cue get go' assumes that the package
cuelang.org/go/cmd/cue/cmd/interfaces will be available. That is to say,
either cuelang.org/go is the main module or, more likely, that
cuelang.org/go is a module dependency of the main module. However, this
is an unnecessary restriction and one that is potentially incorrect.
After all, the user is using a specific version of cmd/cue - loading a
different version of cuelang.org/go seems likely to lead to version-skew
related problems.
This change switches cmd/cue to instead load
cuelang.org/go/cmd/cue/cmd/interfaces via a simple embedding of the
GoFiles in that package.
As part of the same change we surface all loading and type checking
errors for either the embedded cuelang.org/go/cmd/cue/cmd/interfaces or
the arguments to 'cue get go'.
We also migrate the TestGetGo to be a testscript test:
cmd/cue/cmd/testdata/script/get_go_types.txt
This test encompasses all the checks for the various rules/edge cases of
type mappins in 'cue get go', e.g. the mapping of certain Go types to _
or string.
We also introduce more basic tests that verify the behaviour of 'cue get
go' when given a main module package, as well as a non-main module
package (a dependency that should already be resolvable via the main Go
module).
Note: it doesn't seem worth adding/testing GOPATH support given that modules
will be GA in Go 1.16. Indeed we have not had explicit GOPATH tests for
some time/ever. This change also signifies an end to our support for
GOPATH - if it works it will be by accident.
In a later change we will enforce the entirely reasonable requirement
that the main Go module (which we are using to resolve the arguments to
'cue get go') and the main CUE module into which we are writing the
result of 'cue get go' (either within the main module or the cue.mod/pkg
directory) are aligned in terms of their module paths. This will allow
us to drop the --local flag as part of our renaming 'cue get go' to 'cue
import go'.
We leave the enforcing of setting GOFLAGS=-mod=readonly whilst loading
the arguments to 'cue get go' to a later change. This is preparation
towards 'cue import go' but will require a bit more work.
With thanks to @verdverm and @NicolasRouquette for the analysis and
suggestions that went into this fix.
Fixes #621
Change-Id: I630e2cb167c05d63186aa356eaf70a58749b61c5
Reviewed-on: https://cue-review.googlesource.com/c/cue/+/8021
Reviewed-by: CUE cueckoo <cueckoo@gmail.com>
Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
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.