-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go back to --omitNull instead of --omitEmpty #86
Comments
I am convinced |
Now that dhall's default behaviour is to to omit nulls I think we should also reflect it here going back to using This will help cover all the use cases. I have been bitten by this issue in EarnestResearch/dhall-packages#49 (but i can't remove the --omit-empty flag until dhall-kubernetes does) and we resorted to using a dummy value, but it's not optimal |
Fixes #86 The motivation of this is to more accurately model the Kubernetes API semantics by not auto-omitting empty fields. This is because a field set to `Some ([] : List T)` is not necessarily the same as `None (List T)`. This makes the typical case a bit more verbose (more `Some`s), but the difference to the `./examples` shows that it's not too bad.
Fix is up here: #110 |
Fixes #86 The motivation of this is to more accurately model the Kubernetes API semantics by not auto-omitting empty fields. This is because a field set to `Some ([] : List T)` is not necessarily the same as `None (List T)`. This makes the typical case a bit more verbose (more `Some`s), but the difference to the `./examples` shows that it's not too bad.
This change update the kubernetes binding to use the new Optional types. The main consequence is that all the fields that are optional needs to be prefixed with Some. This let us remove the `--omit-empty` parameter resulting in cleaner resources where we don't need to set a dummy emptyDir medium value. See this issue for the details: dhall-lang/dhall-kubernetes#86 Change-Id: I23a0a028909208cd58f57a6f07ee93090b3f3a1a
Fixes dhall-lang/dhall-kubernetes#86 The motivation of this is to more accurately model the Kubernetes API semantics by not auto-omitting empty fields. This is because a field set to `Some ([] : List T)` is not necessarily the same as `None (List T)`. This makes the typical case a bit more verbose (more `Some`s), but the difference to the `./examples` shows that it's not too bad.
... 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:... 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 adelete_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 fewSome
s. Now that we have the::
operator (which has higher precedence thanSome
) it's actually not that bad to just keep all theSome
s for non-required fields. Also if theSome
s were to really become problematic we could always revisit that in this issue:The text was updated successfully, but these errors were encountered: