Reconsider jinja2

[supakeen]

jinja2 is used extensively in Ansible. Many users are familiar with its workings there. We could support it in the same way which would let us to not need our otk.op.* directives.

jinja2 is shipped in RHEL (due to Ansible). It would not be a lot of work to support the same.

The disadvantage becomes that we lose our language agnosticism for the implementation of the specification. Note that shedding that idea might be beneficial due to #62, #47.

[supakeen]

This would also apply to:

• Default variable values (RFC: Default values for otk.define and default values of ${} #17).

If we consider more Ansible-isms we could support when and loop which would apply to:

• RFC: loops for customizations #59.
• Having conditionals.

[mvo5]

During the most recent discussions we found no (strong) use-case for jinja2, the closest is how to join a list to a string (c.f. https://github.com/osbuild/otk/pull/83/files#diff-4887983a602cc028a3825636e5f53de81f3f0fd9b119f91f9bb6825cd1e17caaR12 ) but introducing jinja2 just for that seems overkill so for now it seems jinja2 is out (unless we find a different and compelling use-case).

[supakeen]

Correct, let's close this issue as it won't be necessary for our initial plans.