The most common problem arises when your Ansible module's argument/option expects an integer for example, but because jinja (using filter such as arg="{{ my_var | do_something }}" returns a string, so the spec of your module will reject the input!
This is a hit or a miss in implementation. Dict, list, boolean, float, int, str are all acceptable primitives that must be handled properly.
While the changes in Jinja are welcome, maybe, just maybe, Ansible should consider not using yaml for absolutely everything. There can be more sensible ways to store data sometimes. Just saying.
> ... maybe, Ansible should consider not using yaml for absolutely everything.
Maybe. But what problems with Ansible are you trying to solve by using additional, and perhaps domain specific, languages?
I haven't used Ansible, but I do use SaltStack, which also relies on YAML, and also uses Jinja, hence my interest here.
SaltStack, and I'm assuming Ansible can do this too, will happily use whatever you want, even raw python, as state (configuration) files, so long as they can generate yaml.
This is not as inelegant as it sounds :) -- it means configuration length & complexity can be represented by (or hidden behind) short, palatable algorithms.
As soon as the suggestion is made to introduce yet another DSL to a system, you end up with holy wars about which one, and then a total mess trying to integrate and support both.
Anyway, if you don't want to use YAML / Jinja, then eschew SaltStack, Ansible etc in favour of Chef, Puppet, SCCM, etc.
Mako and Jinja (until this release) really did not differ all that much with regards to this feature. However the ansible community outlined enough reasons for why they are interested in this.
Imagine an xmlrpc client module that could use any xmlrpc API and you wouldn't need one module for every task in the API. Which is the case now in the ansible modules.
But the module can't send an actual integer to the API if the API expects an int. It always came out as a string.
This is due to the issue with native types.
You could add logic to recognize integers and let users specify if they want integer conversion of values or not but that's a lot of extra crud for something that could be very simple.
I wish Python had more templating engines like Jade (now Pug), Slim & HAML. I can't go back to writing HTML anymore. I know about PyJade but it's (and all it's forks) seems always highly unmaintained.
I must say, I almost always try to swap in Mako for Jinja -- instead of learning yet another DSL for templating, I can just use a very good language I already know in my templates: Python.
A templating engine does a few things differently than printf. Typically, it will compile into an intermediate version, for scripting languages like python as a module or object in the language. Most importantly, it escapes the input to prevent arbitrary HTML injection, for example a user inserting a <script> tag in a blog post content causing the javascript to be evaluated. Often, template engines have features for making it easier to design web user interfaces such as template inherritence and composition so you can share things like layouts, headers, and menus across pages.
What it does: http://jinja.pocoo.org/docs/2.10/nativetypes/