Exploring the "gaps" between cue get go and encoding/gocode/gocodec.Codec.ExtractType

[myitcv]

Consider the following situation:

We are writing a command called hello in Go (example.com/hello is the module path). hello is driven by a -config flag, which accepts a CUE input (see cue help inputs). -config can appear multiple times.

We want the source of truth for this configuration to be Go code. Therefore we define Config and associated types in Go and have the CUE definitions follow from that:

type Config struct {
	Inputs []Input
}

type Input struct {
	Name   string
	Source string
}

As authors of hello, we use cue get go --local example.com/hello to generate #Config and associated definitions from the Config Go type. These will then be available in the example.com/hello CUE package for anyone who might care to use them (the definitions are effectively part of the "API" of hello so it makes sense to publish this "API").

At runtime (i.e. when the user invokes hello), we want to validate the configuration passed to us. First we unify the provided -config CUE instances. Next we want to validate the result against the schema generated from the Config type, that is to say #Config and friends.

The question is: at runtime, how do get a cuelang.org/go/cue.Value that is the #Config definition?

The cue get go generated .cue files are not guaranteed to be available; that is to say, either we are in the context of a CUE module at all, or the main module in context does not resolve example.com/blah. Therefore, loading (via cuelang.org/go/cue/load) the definitions at runtime in this way seems brittle.

The *cuelang.org/go/encoding/gocode/gocodec.Codec type defines an ExtractType method. Conceivably we could call this method passing Config{} as an argument. However:

• the extracted CUE value is not (currently) a definition, nor are any of the referenced types (e.g. Input in this case):

{
        Inputs?: *null | [...{
                Name:   string
                Source: string
        }]
}

• it isn't immediately clear how interfaces (discussed in Better support for interface types in cue get go #462) would be supported

The approach I am following today involves embedding the result of cue get go into a string constant in Go code (via a go:generate directive) and then using cuelang.org/go/cue.Runtime.Compile. This works and has the added benefit of being entirely consistent with example.com/hello CUE package.

However I'm raising this for discussion to get thoughts/ideas/feedback from others.

Thanks in advance

[cueckoo]

This discussion has been migrated to cue-lang/cue#463.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.