Better error diagnostics

[kshpytsya]

First of all, cuelang is a real "dream come true" in its domain.

I have successfully embraced it to implement a complex hierarchical multi-environment, multi-region, blue-green, multi-app configuration producing k8s (consumed by flux) and some other artifacts (including user readable README describing current configuration and providing links to useful configuration-specific resources). That is a bit shy of 3Kloc of cuelang. The thing is layered in several levels of complexity, allowing my colleagues to easily do typical things, more-or-less easily do slightly more complex changes, and rely on my effort to implement new structural features.

One general issue is a regular pain point: whenever something breaks, either when I try to introduce some new feature, or, as today, I try to upgrade to v0.12, pinpointing the error cause is very time-consuming, and mostly involves removing large chunks of code or trying to recreate relevant pieces of code in a separate cue project.

Error messages from cue, such as

all_files.#ob.all.1.hr.#v: invalid interpolation: invalid interpolation: invalid interpolation: field not allowed:
    ./z_generate.cue:90:3
    ./k_helm.cue:12:15
    ...snipped 30 more locations...

are often not very helpful.

I feel like I am missing something and there is a better way for tackling this. I thought that one of the following flags could help

Global Flags:
  -E, --all-errors   print all available errors
          --trace        trace computation
  -v, --verbose      print information about progress

but the seemingly do not do anything.

I there any way to have cue eval -e to provide a better insight as to what exactly it doesn't like? Maybe something like an interactive debugger/inspector or some Graphviz visualizations. I would take anything that would improve my efficiency.

[myitcv]

Hi @kshpytsya

First of all, cuelang is a real "dream come true" in its domain.

Great to hear! And thank you for taking the time to offer some feedback.

The topic of improving error messages, more precise errors, better in-editor errors is a key part of the motivation for evalv3, the next generation of the core CUE evaluator. evalv3 has been rewritten in places to help enable future performance changes, but also to facilitate better error tracking and reporting.

We also feel like another key part of the error "story" is different means of exploring errors, along the lines of what you suggest. CUE errors are, it seems, quite different from errors in other languages. They have more context, structure, etc behind them. As such, a tool (whether builtin to an editor or standalone) for exploring errors might well be something that helps in addition to better error messages. In other words, perhaps trying to reduce the expression of an error down to a single line of output in the terminal is where we are going wrong.

Any insights/ideas from you and others in this or any regard would be greatly appreciated!

Thanks again for taking the time to offer constructive and well-reasoned feedback on CUE.