cmd/cue: `vet` with non-CUE files doesn't mention which non-CUE file is missing required fields

[jpluscplusm]

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

$ cue version
cue version v0.6.0-rc.1

go version go1.20.6
      -buildmode exe
       -compiler gc
       -trimpath true
     CGO_ENABLED 0
          GOARCH amd64
            GOOS linux
         GOAMD64 v1

Does this issue reproduce with the latest stable release?

n/a (required fields not available <0.6)

What did you do?

! exec cue vet schema.cue 1.yml
stderr 1\.yml
-- schema.cue --
required!:  string
optional?: bool
-- 1.yml --
optional: true

(Whilst working in the same sphere that led to my opening #2511): I noticed that when cue vet is vetting non-CUE files, and one of those non-CUE files is missing a required field, cue vet produces an error that only mentions the CUE file(s) that are in scope. It doesn't mention the non-CUE file that's at fault.

What did you expect to see?

I expected to see some mention of the non-CUE file that failed to satisfy vet when unified with the CUE that's in scope. I expected this because when I'm vetting multiple non-CUE files I need to see which of them are missing required fields, notwithstanding #2511's limit.

What did you see instead?

$ testscript no-filename-mentioned.txtar 
> ! exec cue vet schema.cue 1.yml
[stderr]
required: field is required but not present:
    ./schema.cue:1:1
[exit status 1]
> stderr 1\.yml
FAIL: /tmp/testscript1585510356/no-filename-mentioned.txtar/script.txtar:2: no match for `1\.yml` found in stderr
error running no-filename-mentioned.txtar in /tmp/testscript1585510356/no-filename-mentioned.txtar

[jpluscplusm]

Replicated with v0.8.0

[myitcv]

Can we in general know that a specific file is "at fault" where a field is missing? Perhaps in some situations, but it's not clear to me that we can know this in all situations.

For example:

! exec cue vet schema.cue 1.yml 2.yml

-- schema.cue --
required!:  string
optional?: bool
-- 1.yml --
optional: true
-- 2.yml --
other: true

[jpluscplusm]

Can we in general know that a specific file is "at fault" where a field is missing?

Given that each data file is vetted in isolation, I believe we can - at least with regards to required fields.

Perhaps in some situations, but it's not clear to me that we can know this in all situations.

For example:

! exec cue vet schema.cue 1.yml 2.yml
-- schema.cue --
required!:  string
optional?: bool
-- 1.yml --
optional: true
-- 2.yml --
other: true

I'd expect both files to be flagged up as missing the required field.

[myitcv]

Given that each data file is vetted in isolation

Ah yes, that's the "edge" I keep forgetting about. We should link this issue to the issue where we discuss whether/how that should remain inconsistent with the behaviour of cue export etc with respect to non-CUE files.

[jpluscplusm]

EDIT: this example has been broken out into https://github.com/cue-lang/cue/issues/3186

---

This also strikes in the following cue cmd context, under CUE v0.9.0-alpha.5:

! exec cue cmd exampleCommand
cmp stderr out
-- a_tool.cue --
package example

import (
    "time"
    "encoding/json"
    "tool/http"
    "tool/cli"
)

command: exampleCommand: {
    fetch: http.Get & {
        url: "https://proxy.golang.org/cached-only/cuelang.org/go/@v/v0.8.2.info"
    }
    validate: json.Unmarshal(fetch.response.body) & #Schema
    display: cli.Print & {
        text: json.Marshal(validate)
    }
}

#Schema: {
    Version!:   string
    Time?:      time.Time
    aBogusField!: string // this field isn't present in the JSON fetched over HTTP
    ...
}
-- out --
command.exampleCommand.display.text: invalid string argument: field is required but not present:
    ./a_tool.cue:15:2
    ./a_tool.cue:14:50
    ./a_tool.cue:16:3
    ./a_tool.cue:23:2
    tool/cli:4:3

There's nothing specific about the use of the HTTP source, but this is the context in which I've experienced the issue striking.

This issue renders the simple implementation of a "fetch some remote data and validate it" workflow command ineffective. Whilst it might be worked around using more complicated CUE, I feel this implementation should be achievable.

[myitcv]

This also strikes in the following cue cmd context, under CUE v0.9.0-alpha.5:

Please create a separate issue for this. It's not immediately obvious that it's the same issue.

[jpluscplusm]

Please create a separate issue for this. It's not immediately obvious that it's the same issue.

https://github.com/cue-lang/cue/issues/3186 opened.