cue/load: support specifying that a package value conforms to a schema

[myitcv]

Is your feature request related to a problem? Please describe.

A number of tools that use CUE ask/require their users to provide CUE input. This almost always requires the user to write a concrete configuration that satisfies a schema that is defined by the tool.

For example, a Dagger plan looks like this:

package todoapp

import (
  "dagger.io/dagger"
  "universe.dagger.io/netlify"
)

dagger.#Plan & {
  // ...
  actions: {
    // ...
    deploy: netlify.#Deploy & {
      // ...
    }
  // ...
  }
}

It's also often the case that the user is providing a configuration file/package in a well defined place, after running $tool init or similar. For example, in the root of a CUE module.

When writing the concrete configuration, it's frustrating for every Dagger user to have to import dagger.io/dagger and effectively wrap their configuration with:

dagger.#Plan & {
    // ...
}

For one, this indents the entire configuration, even though the resulting value is embedded to the package value.

Noting that with must() or a similar approach, we would be able to embed a constraint that forces the package value to satisfy the dagger.#Plan definition without opening the definition. But this would still suffer from the same requirement that the user import and embed such a constraint, an unnecessary hurdle which immediately raises the question "why do I have to do this every time?"

Describe the solution you'd like

The ability to specify somewhere within cue.mod that a package within the module satisfies a given schema. For example, in the case above, if we assume the CUE config file was sitting at the root of a CUE module, the configuration would need to map the module root package to be constrained by dagger.io/dagger.#Plan.

It should be possible for tools to declare such configuration, as well as humans.

This should be a native method supported by cue/load, so that all CUE-related tooling understands the constraint.

Describe alternatives you've considered

• As discussed above. Requiring the user to import and add a constraint in each configuration.
• Adding custom load logic in each tool. We definitely want to avoid this approach, because it will prevent other CUE tooling from understanding the intent of the configuration author.

Additional context

n/a

[myitcv]

cc @hugosantos