Go back to --omitNull instead of --omitEmpty #86
Description
... which would imply wrapping all of the non-required fields in Optional.
I'll admit that I originally proposed --omitEmpty as part of #46 but in retrospect I think it may have been a mistake, for a few reasons:
One example is the issue described in #78 caused by using --omitEmpty. There @ari-becker quoted this from the documentation:
A label selector is a label query over a set of resources. … An empty label selector matches all objects. A null label selector matches no objects.
... but when you use omitEmpty there is no way to distinguish a present but empty field (which means to match everything) from an absent field (which means to match nothing). They are semantically distinct!
Similarly, #77 was caused by the same problem: accidentally omitting a field that was a record where transitive fields were all empty (the default EmptyDirVolumeSource), and that was semantically not the same thing.
Also, more generally, Kubernetes is not the only configuration format that has issues like these. For example, I ran into a similar issue when working on encoding the Mergify configuration format in Dhall as part of this chapter of the dhall-manual. It has a delete_head_branch field that stores a value of type {} and with --omitEmpty there is no way to preserve that field.
The reason I'm bringing up non-Kubernetes examples is because I'm trying to slowly come up with best practices as part of writing the Dhall manual and it's becoming increasingly clear to me that --omitEmpty is an anti-pattern that leads to issues like these because it runs the risk of throwing away semantically significant information.
You also don't gain much these days since all that --omitEmpty buys you is omitting a few Somes. Now that we have the :: operator (which has higher precedence than Some) it's actually not that bad to just keep all the Somes for non-required fields. Also if the Somes were to really become problematic we could always revisit that in this issue: