Initialize a local CUE module. We will not publish this module:

$ cue mod init glacial-tech.example/frostyapp@v0

We refer to such a module as the main module. Because we won’t publish this module, its module path is not significant. The module path we have chosen makes this guide consistent with its companion tutorial Working with a custom module registry.

Create the code for the new module:

package frostyapp

import "github.com/cue-labs/examples/frostyconfig@v0"

config: frostyconfig.#Config & {
	appName: "alpha"
	port:    80
	features: logging: true
}

This imports the frostyconfig package first introduced in the tutorial Working with a custom module registry. Instead of depending on a version of that module published to a custom registry, we have instead published a version to the Central Registry. In our local module we define some concrete values for the configuration, constrained by the frostyconfig.#Config schema.

Ensure the module is tidy, pulling all dependencies:

$ cue mod tidy

If you see an error message mentioning “too many requests” then login to the Central Registry and re-run this command. The Central Registry allows more requests from authenticated users.

We can see that the dependencies have now been added to the cue.mod/module.cue file:

$ cat cue.mod/module.cue
module: "glacial-tech.example/frostyapp@v0"
language: {
	version: "v0.14.2"
}
deps: {
	"github.com/cue-labs/examples/frostyconfig@v0": {
		v: "v0.0.1"
	}
}

Export the configuration as YAML:

$ cue export --out yaml
config:
  appName: alpha
  port: 80
  features:
    logging: true