Make Module Metadata accessable from CUE

[nxcc]

Is your feature request related to a problem? Please describe.
There is no way to get metadata about the package in a package. If, for example, a configuration is created with cue, it would be desirable in some situations, especially if the packages involved dynamically come from a configuration, to be able to embed the package name and version in the output in order to later be able to trace which packages/versions the output was based on.

Describe the solution you'd like
A new package or a new function that returns metadata such as module name, package name, version and other information from modules.cue

Describe alternatives you've considered
One solution that isn't clean would be to @embed the modules.cue file, but this is currently only possible as plain text. This would also only contain the module information and not the version that the module had in the registry, the package name, if it is a subpackage of the module, would also not be available.

[myitcv]

Thanks @nxcc. This is a very interesting observation. We have talked about this in the past in the context of having cue export (or similar) export structured output (possibly txtar for example) that not only includes the configuration payload (whether that be CUE, JSON, etc) but also meta information of the sort that you are alluding to.

Do you have a particular idea of the format in mind?

[morlay]

May just provide pkg like golang’s runtime/debug.ReadBuildInfo did

https://pkg.go.dev/runtime/debug#ReadBuildInfo

i based tool/flow to implement something simliar https://github.com/octohelm/piper/blob/main/pkg/engine/task/client/module.go#L14
which used like (with my custom cli piper)

package component

import (
	"piper.octohelm.tech/client"

        crkitcomponent "github.com/octohelm/crkit/cuepkg/component/crkit"
)

component: {
	_module: client.#Module & {}
	
	"container-registry": output: crkitcomponent.#ContainerRegistry & {
		spec:  version:       _module.deps["github.com/octohelm/crkit@v0"]
         }
}

once cue could provide the runtime/debug

if could be simple

package component

import (
	"runtime/debug"
)

component: {
	"container-registry": output: crkitcomponent.#ContainerRegistry & {
		spec:  version:       debug.Dep("github.com/octohelm/crkit@v0")
         }
}

[myitcv]

May just provide pkg like golang’s runtime/debug.ReadBuildInfo did

Indeed, that's the kind of information that we had in mind. To be clear, the main thrust of my question is where and in what format that information would be available.

Something that just occurred to me is that this information could, as one option, be available on a per module basis as some sort of special hidden field. That would allow us to expose this information via standard CUE commands (-H with eval for example), and allow it to be extracted via the Go API. But because it's a hidden field it would not interfere with existing evaluations in any way (save for establishing a reserved namespace of hidden fields where we can safely place version information: we might be able to use the __).

On a related note, I've also just raised #3618 because I couldn't find an existing issue (which surprised me, but that's another matter!).