Closed b4nst closed 8 months ago
The role of values.cue
in the module root is to allow Helm-like behaviour (overlay/merge instead of unification/immutability). If you don't care about this behaviour, leave the values.cue
empty and use the #Config
definition to provide defaults. I already moved all things from value.cue
into config in the blueprint. I plan to decommission the old init module and change the docs to make it explicit that CUE defaults should go into the #Config
definition.
Perfect, I think that's a pretty good way for new user to slowly adopt CUE patterns. Thanks for your answer!
When using a list or object disjunction (I'm pretty sure we can find other examples), the value defined in
values.cue
cannot be overridden . On top of that, the error message is not really explicit (despite what it says π ), which can be confusing for people new to CUE.Here's a simple and concrete case to understand the issue
Next add a
fail: [...string]
property in the#Config
definition (my-app/templates/config.cue
), as long as this invalues.cue
Now let's say you wanna use a user supplied value which contains:
Any timoni command (lint, apply) using that value will fail at build stage with:
I was also able to reproduce the same behaviour with a disjunction of different object definition. I did not investigated the source yet but my first guess is that it comes from CUE directly (those kind of override are not permitted by CUE). However this is confusing since we can already do stuff not allowed by CUE (changing a string concrete value for example).
Btw this reminded me of #252 and what @fionera mentioned there: totally dropping the usage of this
values.cue
file and directly using CUE default marker to use default values in the#Config
definition. I find this defaultvalues.cue
behaviour quite confusing tbh. You would only have to provide custom values when needed (bundle, apply, etc...).