following CfgMgmtCamp let me ask the community on certain style questions for Ansible.
In case you already answered in LimeSurvey or in person on the questions - please do not answer on all questions except questions 7, 8,9 below - these questions are the are new ones
Some additional info on questions below:
It is possible to use “dot notation” for dictionaries in many cases. The bracket notation is mandatory the variables use reserved names; for variables that use special characters;
Let’s say that because it is widespread ansible_facts will still use bracket notation ansible_facts['hostname'].
Reference:
it is possible to avoid quotes for most of the strings in YAML, the exceptions are:
If the string contains (e.g. : , { , } , [ , ] , , , & , * , # , ? , | , - , < , > , = , ! , % , @ , \ ).
and
If the value starts with characters like !, &, or #.
Additional reading:
Survey
Q1. What is the preferred dictionary notation?
Dot notation is the preferred notation, if possible
({{ my_dictionary.mykey }})
Regarding meta/main.yml in roles in collections: I think there was a time when galaxy-importer rejected a collection that had a role without this file. That might have changed though… This is I think the only reason why I maintain this file for some of my collections that have roles.
I always use ansible (yaml) style notation especially for lists and dictionaries. If lists are changing, it looks nice in git diffs.
Wonder what do you consider internal variable of the role in this context?
I think that having anything coded in the name is an antipattern and should not be used. My understanding is that this practice is coming from the fact that there is no go to definition and go to references functionality in ansible language server for variables (and for roles). One cannot simply check definition of a variable.
Q2. Is it good practice to prefix internal variables with double underscores (__ ) and use r_ prefix for variables used in “register” task attribute?
When writing a role which requires an internal variable, I usually follow the PEP 8 Style guide for specifying variables with a single leading underscore. Taken from: PEP 8 – Style Guide for Python Code | peps.python.org
The formatting of “block-style” notation got a bit lost in the survey.
Even though all of you might know it let me still provide examples of that, for lists (and also “block-style” might be not much known as a term)
tags:
- install
- configure
users:
name: John
location: ghent
@kks , indeed there is an answer of Daniel. But also roughly that assuming that vars/main.yml typically would contain (some) variables with underscores.
The reference for __ are roles of Jeff Geerling (I guess all of them) and indeed Good Practices for Ansible - GPA , one of the Style Guides that I used
The convention on using r_ for register variables is used more seldomly…
@bvitnik indeed, thank you I have seen it! For me the poll over there was a bit of “semi-final” and I created those 2 options that got into final. And actually right now “ensure” is losing in the final
To me it looks like this recommendation predates argument_specs file. Because with argument specs there is no question what can be set by user.
There are number of questionable recommendations in that document from my point of view.
Quotes that are part of the YAML syntax rather than an actual part of the value.
foo:
a: "In this scalar the \"external quotes\" are 'double' quotes"
b: 'In this scalar the "external quotes" are ''single'' quotes'
c: This scalar has no "external" 'quotes'
The main difference is whether backslash escapes are interpreted.
- these questions are the are new ones
