You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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):
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Originally opened by @myitcv in cuelang/cue#463
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 (seecue 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:As authors of
hello
, we usecue get go --local example.com/hello
to generate#Config
and associated definitions from theConfig
Go type. These will then be available in theexample.com/hello
CUE package for anyone who might care to use them (the definitions are effectively part of the "API" ofhello
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 theConfig
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 resolveexample.com/blah
. Therefore, loading (viacuelang.org/go/cue/load
) the definitions at runtime in this way seems brittle.The
*cuelang.org/go/encoding/gocode/gocodec.Codec
type defines anExtractType
method. Conceivably we could call this method passingConfig{}
as an argument. However:Input
in this case):The approach I am following today involves embedding the result of
cue get go
into a string constant in Go code (via ago:generate
directive) and then usingcuelang.org/go/cue.Runtime.Compile
. This works and has the added benefit of being entirely consistent withexample.com/hello
CUE package.However I'm raising this for discussion to get thoughts/ideas/feedback from others.
Thanks in advance
Beta Was this translation helpful? Give feedback.
All reactions