To me this sounds like a reasonable solution. On Friday, December 20, 2019 at 6:51:59 PM UTC-5, tazjin wrote: > > Original reply from me: > > I'm thinking that in hindsight overriding the default function may have > been the wrong approach. The main issue that got us to do that is that > Sprig's default doesn't work in combination with the templater setting that > checks for missing values, but a more sensible way to work around that (now > that I'm thinking about it again) is probably to instead simply provide a > getter function that can work with absent values. > > This is closer to what @phillipj originally > suggested in that PR. I missed cases like environment-variable reading in this > comment > . > > So if you know a value is "nilable" accessing it would use that function, > which is composable with sprig's default. > > To try to illustrate: > kontemplate 1.6 > > This only has the default default function, and fails on missing key > access. For example: > > foo: {{ .unsetValue | default "default value" }} > > This will result in an error because unsetValue is not set in the cluster > context. default is never called. > kontemplate 1.7 > > We now have the custom default function, but we can only use it with > context variables: > > foo: {{ default "default value" "unsetValue" }} > > Would return foo: default value if unsetValue isn't set, and the value of > that key otherwise. Now we run into the issue of calculated or otherwise > externally retrieved values being "piped" into this like @ilyavw points out. > kontemplate, in the future? > > Here we would revert back to the normal default function and introduce a > new function, perhaps called maybe (in the style of Haskell's sum type > representation of absent values) that can read a value by string index and > retrieve it even if unset: > > foo: {{ maybe "unsetValue" | default "default-value" }} > > Thoughts on this? In order to avoid doing a breaking change immediately > (as there are now users of both patterns), I would leave the current custom > default as the ... default-default (sorry) and add a soft-deprecation > warning printed to stderr, as well as feature-gate the sprig default > behind some CLI flag. In the next version after, the custom default would > be removed, giving people some time to make changes were necessary. > > Thoughts on that? > > On Fri, Dec 20, 2019 at 11:51 PM Vincent Ambo > > wrote: > >> Originally reported as GitHub #156 >> by katherine-black >> . This thread has an important reply >> which I will add to the mail thread as a response. >> >> ---------------- >> >> Hello, unfortunately I ran into some issues when updating to kontemplate >> 1.7.0 and trying to use the new default function. >> >> Currently our templates used the old function in the following way: >> >> {{env "FRONTIGRADE_REPO_URI" | default .frontigrade.repoUri}} >> >> Where we try to have everything configured with env vars (fed in by >> gitlab-ci) and if it's missing, we fall back on values defined in our >> config file. >> >> After updating I assumed the new pattern would be: >> >> {{default "frontigrade.repoUri" (env "FRONTIGRADE_REPO_URI"))} >> >> But that returned the string frontigrade.repoUri every time, whether >> FRONTIGRADE_REPO_URI was set or not. >> >> I've also tried to find documentation on the new default function, but >> besides some discussion in the PR here >> I didn't really find >> anything. This was even more confusing as I kept stumbling on the default docs >> from sprig. >> >> Finally, my questions. Am I just missing something? I admit I'm not a go >> expert so I could totally be missing something. Would it be possible to >> restore the previous default function somehow? >> >