# (1.2/development feature) Variable/conditional cleanup in progress

**URL:** <https://forum.ansible.com/t/1-2-development-feature-variable-conditional-cleanup-in-progress/12619>\
**Category:** Ansible Project\
**Created:** [April 3, 2013, 5:15am UTC](https://forum.ansible.com/t/1-2-development-feature-variable-conditional-cleanup-in-progress/12619 "2013-04-03T05:15:10Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 3, 2013, 5:15am UTC](https://forum.ansible.com/t/1-2-development-feature-variable-conditional-cleanup-in-progress/12619/1 "2013-04-03T05:15:10Z")

</div>

A common request for Ansible is that we have easier to use  
conditionals and variable operations, or occasionally that something  
like lowercasing a variable is made possible. Until now, that hasn't  
/really/ been possible.

I've submitted a very early patch for 1.2 that allows use of Jinja2  
statemnets in Playbooks.

I've managed to do this in a way that is at least as fast as the  
current templating system, which I think is pretty nice.

Basically:

- debug: msg={{ foo }}

Would expand foo, just as $foo does today.

This may sound trivial, but in chat some folks want to do things like  
get a fact from the very first server in a particular group, and then  
the syntax gets a lot more complicated than $foo, and it's nice to  
just use regular old python variable syntax.

So far there are some caveats -- I haven't tested this with  
conditionals yet, but when I do, it's just going to need to use  
regular old only\_if for now, and then we can make a simpler one called  
'when' that can also 'booleanify' things like 'yes', 'y', positive  
numbers, or 'yup', etc, through standard truthiness rules.

This should really greatly simplify things.

The one other restriction right now is you can't use $foo and {{ foo  
}} on the same line, which means I need to make a function available  
to both kinds of Jinja2 templates to access lookup plugins to  
eliminate the need to use the $MACRO form ($FILE, etc).

Because we take a hard line on backwards compatibility, my plan on  
this is to keep the existing template system around forever, so  
everybody's content keeps working... we may revisit that decision in a  
year, though once we get things streamlined, all the docs/examples  
will move over to use the new simpler form.

Testing is needed and I'm sure we'll find other limitations and things  
we need to fix -- in particular, Jinja2 is a little fiddly about  
Unicode, though I've tested things with some characters outside the  
Latin character set and it seems fine. It does appear the callbacks  
might need to display things as UTF-8 in a few places.

In any event, check it out, and I will do some more on this to get  
lookups to work and to come up with some nice conditional examples  
shortly.

Technically this above feature should also allow other features in  
Jinja2, like {% if %}, however I don't recommend anyone get the idea  
to use these in the playbook. Jinja2 is a templating construct, and  
it would be a mistake to use them for logic here. If I can find a way  
to disable this I will, especially because this isn't templated YAML  
at all, this is a templated STRING inside the YAML (which means it is  
still valid & parseable data).

1.2 users should be able to try this out now.