cueconfig with environment variables

[aranw]

Hey so recently @myitcv did a talk at London Gophers and demo'd the https://github.com/cue-exp/cueconfig project which I think @rogpeppe worked on and this project looks ideal to meet the configuration needs for how I'd like to configure services.

For context the previous discussion can be found here in the Cue Slack

The only issue with the way currently most Cue examples and cueconfig work is that they use JSON/YAML/Cue to define the configuration and this is fine I think for Go programs/clis/etc but for services that are deployed to Kubernetes it doesn't quite fit our needs and I was hoping to try brainstorm a way to utilise cueconfig and Cue schemas with environment variables

We often have a Config struct that will look something along the lines of:

type Config struct {
	Debug bool `env:"debug"`
        GCP_Project string `env:"PROJECT,required,overwrite"`
        GCP_Region  string `env:"REGION,required,overwrite"`
}

We often use sethvargo/go-envconfig to load the environment variables and do some basic validation for required fields.

Perhaps there may also be some nesting and also perhaps we might add validation onto this as well to ensure correct values are given such as integers within a certain range or time durations etc

Unfortunately theres not really scope to switch from environment variables and this would add a lot of complication to the k8s charts and helm charts that right now can't really look to change

I'd ultimately like to use Cue Schemas and Cue validation to simplify developers experience with configuring services e.g. they create a Cue Schema, define the constraints for values, set defaults, etc and then we can generate out the necessary Go structs.

Perhaps in future provide embeddable Cue Schemas from additional libraries perhaps using the upcoming Cue modules to add additional configuration options (but this is perhaps a bit out of scope of this discussion but will hopefully give an idea maybe of how I might like things to work in the future)