[nine_k]

Go find a place where the struct value is clearly defined.

It may seem that any definition is final, but none is. Since the last definition of a struct field overwrites a previous one, the order in which e.g. files are interpreted matters. It's like writing a config by using Python dicts, with the added complication that creation of a new one and updating of an existing one are indistinguishable.

This may be okay in practice, given some discipline.

[from-nibly]

No it cant overwrite values. It has to agree or it will throw an error.

You can have wider types being overridden by more closed types. e.g. string => "this literal". But you cant have two disagreeing values.

I use this to create kubernetes manifests at work, at a reasonably large scale. The inability to join multiple files without fear of collision is specifically one of the best features.

[Sadzeih]

As someone who works with Kubernetes every day and has been curious about CUE for some time, can you describe a bit how you're using it to create manifests? Did it replace helm for you? Or is it to create CRDs?

Edit: I'm struggling to see where it fits in the whole k8s ecosystem.

[from-nibly]

It creates all the stuff that isnt in helm charts already for me. Im probably abusing it at the moment but ill see if I can make a gist and post the link. Bascally though I have a single massive package with a monolithic object. That goes env -> namespace -> resourceName -> resourceType -> resourceManifest.

Then I have a tool file that loops through that and renders it into fall files. Then argocd picks that up in chunks with application files.

Its awesome cause it lets me set project wide defaults and restrictions. It also lets me do stuff like. "If there is at least one manifest called x create an argocd application for it automatically" or " loop through these repos and create an app for each one with the following properties"

[nine_k]

Hmm, looks better this way!