Re: [ops/kontemplate] Can't access sub-values in the new default function

Re: [ops/kontemplate] Can't access sub-values in the new default function

[iwhite]

[-- Attachment #1.1: Type: text/plain, Size: 4020 bytes --]

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 <https://github.com/phillipj> originally 
> suggested in that PR. I missed cases like environment-variable reading in this 
> comment 
> <https://github.com/tazjin/kontemplate/pull/148#issuecomment-401386577>.
>
> 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 <javascript:>> 
> wrote:
>
>> Originally reported as GitHub #156 
>> <https://github.com/tazjin/kontemplate/issues/156> by katherine-black 
>> <https://github.com/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 
>> <https://github.com/tazjin/kontemplate/pull/148> 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?
>>
>


[-- Attachment #1.2: Type: text/html, Size: 18520 bytes --]