As described on the previous page, each cue export invocation first identifies and reads its inputs.

Inputs must be readable

If any of the inputs can’t be read, the command fails with an error message:

package one

data: true

$ cue export .:two
build constraints exclude all CUE files in .:
    1.cue: package is one, want two

Default expression

After the inputs are read successfully the command evaluates a single CUE expression. By default, this expression is the entirety of the configuration that was specified as the command’s input:

package one

data: true

$ cue export .:one
{
    "data": true
}

If evaluation is successful then the value of that same CUE expression is emitted in a manner that’s controlled through the flags described on the next page.

Modified expression

If you want to evaluate a different expression from the default, specify it with the --expression (-e) flag:

package one

foo: {
	A: 1
	B: 2
}
bar: C: 3

$ cue export .:one -e foo
{
    "A": 1,
    "B": 2
}

Constraints that aren’t involved in the expression’s value are not evaluated. In this example, notice that the struct bar contains two values for the field C that can’t unify, and yet the command still succeeds:

package one

foo: {
	A: 1
	B: 2
}
bar: {
	C: 3
	C: 4
}

$ cue export 1.cue -e foo
{
    "A": 1,
    "B": 2
}

To validate an entire configuration before exporting part of it, use cue vet before you run cue export.

Issue #3371 tracks a bug where the entirety of a CUE package input must evaluate successfully, no matter what value is provided for the --expression (-e) flag.

Flexible expressions

The --expression (-e) flag takes an expression, which gives you flexibility when formulating the value to be evaluated and emitted:

package one

foo: {
	A: 1
	B: 2
}
bar: {
	C: 3
	D: 4
}

$ cue export .:one -e '{ onlyFoo: "foo": foo }'
{
    "onlyFoo": {
        "foo": {
            "A": 1,
            "B": 2
        }
    }
}

Note the use of double quotes in the expression, around the "foo" label. They allow CUE to distinguish the label from the underlying foo field. They are required in this very specific case, where the emitted label needs to match the field’s name, but where the field’s value would be shadowed if the quotes weren’t present.

Non-concrete expressions

A cue export invocation fails if the value of the evaluated expression isn’t concrete – in other words, if some part of its value can’t be represented in a data-only format such as JSON. Examples of non-concrete values include types such as string and constraints such as >=100:

A: 1
B: number
C: <=99

$ cue export data.cue
B: incomplete value number:
    ./data.cue:2:4
C: incomplete value <=99:
    ./data.cue:3:4

Evaluation insight

The CUE evaluator can emit statistics about each evaluation it performs. For more details, read Logging statistics from the CUE evaluator.

Related content

• Reference: The cue export command
• Reference: cue help vet
• How-to Guide: Logging statistics from the CUE evaluator