# Conditional imports and other syntax improvements for playbooks

**URL:** <https://forum.ansible.com/t/conditional-imports-and-other-syntax-improvements-for-playbooks/11358>\
**Category:** Ansible Project\
**Created:** [March 20, 2012, 2:58am UTC](https://forum.ansible.com/t/conditional-imports-and-other-syntax-improvements-for-playbooks/11358 "2012-03-20T02:58:16Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [March 20, 2012, 2:58am UTC](https://forum.ansible.com/t/conditional-imports-and-other-syntax-improvements-for-playbooks/11358/1 "2012-03-20T02:58:16Z")

</div>

Earlier I wrote about external variable files when Smooge was asking how to protect against keeping confidential data in source control.

[http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data](http://ansible.github.com/playbooks.html#external-variables-and-sensitive-data)

The question came up today about conditionals, and how we could handle them. For the most part, I’m a big fan of separating the “what” from the “how”. This keeps syntax clean, as i don’t believe infrastructure recipes to look like a bunch of Perl code threw up all over them.

Here’s what I came up with:

[https://github.com/ansible/ansible/blob/master/examples/playbooks/playbook3.yml](https://github.com/ansible/ansible/blob/master/examples/playbooks/playbook3.yml)

There are a few new concepts, for which I’ll probably document tomorrow for the web site.

B: Variables that bubble up from facter & ohai can be used to decide what to import. You have choice so you can install facter, you can install ohai, or you could install both. I test with both, actually. If you don’t have any of these, no errors will occur, you just won’t be able to substitute any variables in.

C: Per Seth’s suggestion, $foo is now a perfectly valid alias for {{ foo }}. This is not valid inside Jinja2 templates on the managed machines, though, so take note of that. I think this makes playbooks look a lot cleaner.

D: It’s legal to use variables to name your modules. This is kind of a ghetto-provider interface, and to be honest, I don’t expect it to be used at all. If we do it right, when aptitude comes along, we can put everything into a common module and rename the yum module to “package”.

Aside for some much overdo refactoring and logging upgrades this should be solid – the unit tests in source control also cover this now.

Another thing that I want to do, that I haven’t done tonight, is to give each task an “onlyif” clause, allowing the module to be easily skipped if an expression evaluates to false, ex:

onlyif: $facter\_operatingsystem == ‘Debian’

That will further enhance things to be reasonably powerful in terms of capabilities, while still avoiding a lot of nesting and bloated syntax in the playbooks.

–Michael