cmd/cue: add 'mod schema' command
Is your feature request related to a problem? Please describe.
I tried to find and run a cue command that showed me the effective schema applied to a cue.mod/module.cue file when validating such files. I want to consume this CUE in another process (specifically I want to render the CUE on cuelang.org in the modules reference documentation https://cuelang.org/docs/reference/modules/#cue-mod-file, rather than maintaining that copy by hand).
Describe the solution you'd like
Something like this:
cue mod schema module.cue
that would then output the raw CUE used to validate a cue.mod/module.cue file.
Note that currently schema.cue specifies a "strict" variant. It is my understanding that we only use the strict variant, and thus this is what I would expect to be output.
Describe alternatives you've considered
Loading https://github.com/cue-lang/cue/blob/19e990d82298ba18ca4b0ca5a0a2a60e13dc3bc5/mod/modfile/schema.cue and using some CUE logic (potentially different from the Go logic in https://github.com/cue-lang/cue/blob/19e990d82298ba18ca4b0ca5a0a2a60e13dc3bc5/mod/modfile/modfile.go) to extract the "latest" schema.
Additional context
n/a
$ cue version
cue version v0.0.0-20240604090448-19e990d82298
go version go1.22.3
-buildmode exe
-compiler gc
DefaultGODEBUG httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
CGO_ENABLED 1
GOARCH arm64
GOOS linux
vcs git
vcs.revision 19e990d82298ba18ca4b0ca5a0a2a60e13dc3bc5
vcs.time 2024-06-04T09:04:48Z
vcs.modified false
cue.lang.version v0.9.0
FWIW another possibility I've had in mind in the past is to make these schemas available in the standard library. Then they'd be available to regular CUE code, not just on the command line.
So, for example, your example cue mod schema module.cue might be expressed as cue def mod/modulefile or similar (modulo whatever naming might be chosen for the import path and/or definition).
Note that currently schema.cue specifies a "strict" variant. It is my understanding that we only use the strict variant, and thus this is what I would expect to be output.
FWIW we use the non-strict variant whenever cue/load loads a module , so it's actually in reasonably common use. I suspect that it might be useful to have both variants available.