cmd/cue: export evaluates constraints outside the --expression flag's context inconsistently

[jpluscplusm]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.10.0

go version go1.23.0
      -buildmode exe
       -compiler gc
       -trimpath true
     CGO_ENABLED 0
          GOARCH amd64
            GOOS linux
         GOAMD64 v1
cue.lang.version v0.10.0

Does this issue reproduce with the latest stable release?

0.10.0 is latest

What did you do?

exec cue export no-package.cue -e foo
exec cue export package-p.cue  -e foo
exec cue export .:p            -e foo
exec cue export data.yml       -e foo

-- package-p.cue --
package p
foo: true
bar: false
bar: true

-- no-package.cue --
foo: true
bar: false
bar: true

-- data.yml --
foo: true
bar: false
bar: true

What did you expect to see?

I expected to see one of these outcomes:

• all invocations succeed, as the unsatisfied constraints are outside the scope of the -e flag
• all invocations fail, as the unsatisfied constraints are evaluated consistently across input types, despite being outside the scope of the -e flag
• the CUE-based invocations succeed, but the YAML-based invocation fails, for some reason.

What did you see instead?

$ testscript -continue cue.export.expressionHandledDifferentlyPackageVersusFile.txtar
> exec cue export no-package.cue -e foo
[stdout]
true
> exec cue export package-p.cue  -e foo
[stdout]
true
> exec cue export .:p            -e foo
[stderr]
bar: conflicting values true and false:
    ./package-p.cue:3:6
    ./package-p.cue:4:6
[exit status 1]
FAIL: /tmp/testscript536191441/cue.export.expressionHandledDifferentlyPackageVersusFile.txtar/script.txtar:3: unexpected command failure
> exec cue export data.yml       -e foo
[stderr]
bar: conflicting values true and false:
    ./data.yml:2:6
    ./data.yml:3:6
[exit status 1]
FAIL: /tmp/testscript536191441/cue.export.expressionHandledDifferentlyPackageVersusFile.txtar/script.txtar:4: unexpected command failure

Context

I'm currently writing a concept guide for cuelang.org that explains cue export. The inconsistency highlighted above will either need to be called out explicitly, complicating the guide; or (preferably; if it's an error) corrected in the command's behaviour.

[mvdan]

Thanks for filing this. From reading cue help inputs, cue export package-p.cue and cue export .:p should have exactly the same behavior, so I think this is definitely a bug.

I think all four commands should succeed, with the assumption that -e only evaluates what it needs to - and it clearly already does that in some cases.

[gregschohn]

I'm trying to setup tests (there might be a better way, but I've not come across anything). Being able to setup granular or hierarchical test patterns and test them without needing to parse through all of the broken output - or more likely, repeatedly comment them out - would be a huge time saver. It could provide a gentler landing for others to pinpoint errors too.

Here's what I'm doing & why this issue impacts it

Test: {
  FeatureA: {
    // ...
  }, 
  FeatureB: {
    case1: ...,
    case2: ...
  }
}

Run w/ Test, Test.FeatureB.case1, etc.

As it stands now, I see errors because of everything that occurred within this file and all the others. I'd like to see the errors only caused by the expression that I've narrowed evaluation down to.