Support exclude key on interpolation for himl
ecojan opened this issue · comments
Himl goes through each value and checks for "{{ interpolation.key }}".
If we want to pass the following value "{{ template custom.value }}" that can be used by an end application, interpolation will fail as custom.value is not found.
It would be nice to have a flag or way to explicitly say a value should not be interpolated.
The only workaround for this is be setting "skip_interpolation_validation=True".
I can see this as a valid use case resolved right now by the flag you mentioned 'skip_interpolation_validation=True'.
Also, excluse will completely remove the key before any interpolation. I'm thinking you want something that will not do validation on specified keys. This has the potential to be missused or get cumbersome with more than a few keys that you need to keep track of.
Can you elaborate more on your use case and why just disabling validation doesn't work?
Can you elaborate more on your use case and why just disabling validation doesn't work?
I see the validation as a safety net, something that must be interpolated but doesn't get interpolated due to an error should come up when running himl. On the other hand if there are some keys that you specifically don't want to interpolate (leave them as they are), here is where I would see the advantage of having an option to exclude the aforementioned key from the interpolation process.
WDYT?
Yes, validation good.
Still interested in your use case, if you can elaborate on that.
At first glance seems you are trying to use hiera as a template engine to template a template and I don't think this is a good use case.
Yes, validation good.
Still interested in your use case, if you can elaborate on that.
At first glance seems you are trying to use hiera as a template engine to template a template and I don't think this is a good use case.
I'm not sure what you are referring to or how hiera is tied in here.
My use case is as follow:
I have the following yaml file in one of the subdirectories traversed by himl
slack_configs:
- channel: my-channel
text: '{{ template "__slack_text" . }}'I'm just trying to ignore the text key during interpolation here as it would crash the himl processing without disabling validation. The value for the text key ( '{{ template "__slack_text" . }}' ) is gonna be used later in the obtained output by something independent of himl (again just trying to ignore a key).
The issue is when using himl on a configuration that needs to be passed to a different application that is using the same format "{{"and "}}"
Seems that what you need is to escape the key value. For example, using double quotes in key: "{{ val }}" resolves the interpolation, but using single quotes key: '{{ val }}' results in the literal {{ val }} string. I think instead of manually ignoring some keys it would be better to support escaping interpolation on values. Would this fit your use case?
Escaping interpolation is the keyword here, yes.
Double quote vs single quote seems weak though.
The himl user should be able to explicitly turn off interpolation within a value.
And it may not be possible to implement, when parsing value in https://github.com/adobe/himl/blob/master/himl/interpolation.py#L17
key: "value", key: 'value' and key: value are equivalent in yaml parser. you get the value string
I've only used quotes as an example on escaping values. Wanted to use something else but thought quotation would be more familiar and easy to visualize.
Cool - makes sense
I think we can use a similar escape sequence as in go templates:
{{`this is a {{value}} that should not be interpolated`}}
/cc @costimuraru
@danielcoman I tried escaping via single quotes vs double quotes.
None of them have worked, they both are equivalent as @amuraru said.
One option that can actually make it work is "--skip-interpolation-resolving" but this is not actual escaping and is turning off other features.
@ecojan Well... it's not implemented. Quotation is only used as an example.
I've only used quotes as an example on escaping values. Wanted to use something else but thought quotation would be more familiar and easy to visualize.
Conclusions from this thread is that the feature needed is not a flag or a list of keys to ignore in interpolation validation, but proper escaping for values.