"Defaultify"

[cueckoo]

Originally opened by @mkmik in cuelang/cue#59

In #33, @mpvl does IMHO a very good job at highlighting the core difference between cue and jsonnet.

I like cue very much; it really has the potential to tame the complexity of configs.

Its generative aspect works well for templating when the templates have been explicitly designed for extension (and arguably forcing the author to be explicit is instrumental for the success of taming the complexity in the first place)

One of my main annoyances with Helm, is that chart authors are effectively forced to expose every possible field of every k8s object as values in the values.yaml template, because sooner or later some consumer of that chart (usually from outside the administrative domain of the chart author) will have a reasonable use case for the override.

In jsonnet, you can just take an upstream yaml or json object, parse it and apply overrides with jsonnet.

For cue to be useful in this scenario, would we need a function that converts a cue object tree into an object tree that replaces every field value x with *x | _.

Then we could do something like (I know that "Defaultify" is a horrible name, cannot currently think of a better name right now):

import (
  "encoding/yaml"
  "override"
)

res: override.Defaultify(yaml.Unmarshal("""
     foo:
       bar:
         a: 1
         b: 2
  """
)) & {
  foo bar b: 10
}

once an external value is lifted into cue value model, it can be further refined applying type and value limitations that make sense to the user.

Perhaps I'm missing something. Is there already a way to achieve this today?

(I saw there is an interesting approach for importing external legacy configs based on source level imports, but I think that solves a different use case)

[cueckoo]

Original reply by @jlongtine in cuelang/cue#59 (comment)

@mkmik Is this similar to what you're looking for? cuelang/cue#15

[cueckoo]

Original reply by @mkmik in cuelang/cue#59 (comment)

Yes thanks, closing as duplicate of #15