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 <ma...@tazj.in> 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?