Documentation updates -- presenting the way 1.2 does variables instead of the old way + 1.1 docs snapshot

Archives Ansible Project
1

Hi everyone,

I’ve pushed some changes to ansible.cc/docs/

The docs now include the 1.2 variables syntax {{ foo }} as favored everywhere, and don’t really mention the other way.

The old variable ways still works and I do not plan to remove it, but wanted the variable documentation to be consistent and I think it’s much cleaner to have it done the one way where people don’t need to think about how do conditionals “the hard way” and so on. It also seems better that the way variables work in templates are how we present things.

So this also just presents the “when” operator and so on versus the old need to preset “when_string” and “when_boolean” or even “only_if” … all cleaner this way.

We still link to the old docs at http://ansible.cc/docs/released/1.1/ and I plan to snapshot docs at release time.

There are likely some errors here and there so as always patches to the docs are accepted, just send me a pull request to docsite/latest/rst/*.rst (note new subdirectory “latest”).

Let me know if there are any questions, glitches, or things that could be more clear.

I suspect this may cause some confusion as it’s not SUPER clear when you are reading the docs this is not the 1.1 docs snapshot, but the time is probably now, and I think the ability to streamline things by presenting the cleaned up methods is a good thing.

One syntax I don’t particularly care for is the form:

asdf: “{{ other_variable }}”

because it’s still “unneccessary quotes”.

I have considered maybe still using $other_variable in this case in the docs. Just seems cleaner for the simple things. Thoughts welcome.

2

I agree that it's ugly but consistency in variables is worth it, I think.
Otherwise as a beginner I'm going to wonder why you're using $blah and {{
blah }} in different places and get muddled up and end up mixing them up to
make ugly playbooks. The quotes suck, but I still prefer it.

3

I think the quotes are perfectly fine. Just mention in the docs they’re needed and why (because curly braces mean an object, like in JSON). You wouldn’t use double curlies in JSON and expect it to work, right?

4

Pretty much, yes.

Good.

I tend to think of ansible playbooks as the language they are and don’t really think of them being YAML, and as such tend to want to think of them as being mallable any way we want.

Though I think it’s just the limitation of the way things are, and we get various benefits (namely, being parseable by machines and easily documented, and not reinventing wheels) by sticking to our guns.

–Michael