Request for merging PR #7278

Archives Ansible Developer
1

Hello,

An example is welcomed, but I don't want to see it sprawling in the
commit message, and I still find this hard to understand.

As such I think this does not fit our complexity threshold criteria.

First of all, I think that commit messages are really important for
understanding changes. I see no problem with them being lengthy and I
think including examples in them can only add to their quality. That
said, if you absolutely think that this particular commit message should
not include an example, I can fix it for you.

As for the functionality that this commit gives us, perhaps it would
help your understanding of this if you think of a nested loop as a tree.
I am copying from one of my posts in the ansible-project list:

With my addition, with_nested is extended allowing you to use item.0,
item.1, etc... in your expressions. The numbers 0, 1, 2, etc.. denote
the loop level. 0 is for the first (outer) loop level, 1 is for one
level deeper, 2 is for one more level deeper, etc... Nothing more,
nothing less, but this addition is quite powerful because it gives you
the ability, in each possible loop branch (think of a nested loop as a
tree, see below), to reference back to the values that were evaluated
in previous loop levels (nodes) in the same branch.

with_nested:
- ['a', 'b', 'c']
- ['d', 'e', 'f']
- item.0

     ,------ 'd' ----- 'a'
    /
'a' -------- 'e' ----- 'a'
    \
     `------ 'f' ----- 'a'

     ,------ 'd' ----- 'b'
    /
'b' -------- 'e' ----- 'b'
    \
     `------ 'f' ----- 'b'

     .------ 'd' ----- 'c'
    /
'c' -------- 'e' ----- 'c'
    \
     `------ 'f' ----- 'c'

0 1 2 <-- loop levels

So, if you are in the 'a' branch of the nested loop, item.0 gives you
'a'. If you are in the 'b' branch, it gives you 'b' and if you are in
the 'c' branch it gives you 'c'.

I am not doing magic. I just follow the nested loop tree and use the
already-available ability to inject things in the template engine. For
each branch in the nested loop, I inject an "item" var with values
corresponding to nodes in that branch. I believe that other developers
could understand this.

Besides, if you still find it difficult to understand this or explain it
to others, please just merge it and make it an undocumented feature. Not
only it will not hurt anyone (it does not break current deployments),
but it will also help people who understand this to do nested loops that
cannot be done without this. So, I do not see a practical reason for
this not to be merged.

2

I am not a big fan of the syntax and also find it confusing.

item.0 is typically used for accessing the first element of item where item is a list.

Having it reference a loop level to me is strange and will no doubt cause confusion.

I have to agree with Michael here. If it is hard to explain, hard to understand and has the potential of confusing others between common sytaxes, it is not following the ansible way. And you’ve just met all three of those “disqualifiers”.

You can always create your own custom lookups that don’t have to be shipped with Ansible. No sense in having an undocumented feature in core for one person, when they could just as easily use a custom lookup.

3

item is still a list which simply contains the values at each loop level. Item.0 is used for accessing the first element in that list. What is so confusing on this? Sorry, but I cannot take that “hard to explain” argument. You already have “with_subelements” with an even more strange use of “item”. item.0 refers to an item in one list, but item.1 refers to an item in another list! Also, you can see people often come back and ask how to do nested loops on some complex data that “with_subelements” cannot handle. My solution can really help them. Why not make it available for everyone in the Ansible community?

4

I should also add that this pull request does not introduce a new concept. The current implementation of ‘with_nested’ does already allow access to the value of each level of a nested loop. Take a look at this example: In the example above, {{ item.0 }} gives the value of the first level of the nested loop, {{ item.1 }} gives the value of the second level of the loop and {{ item.2 }} gives the value of the third level of the loop. This is a proof that Michael’s argument that my pull request adds more complexity to Ansible is not correct. How can it add more complexity to Ansible, when Ansible already allows access to values of each loop level? The only difference is that current implementation allows access to the loop values only at the end of the loop. So, the implementation of ‘with_nested’ in my pull request simply extends this to also allow access to the loop values at any level inside the loop. Maybe my lengthy commit message made you think that I am introducing something completely new? It is not. This is a highly unobtrusive improvement, as well as a really helpful one. So, please, give it a chance.