Hello,
I don’t know if this is normal (feature?) or if it can be considered as a bug that needs to be fixed :
action: …
with_nested:
does not loop over myList with each item referenced as item.0
I always have to go the “with_items: myList” and this breaks my workflow because
- when a task starts needing a nested loop all the item references need to be changed (from item to item.0 for instance).
- I cannot copy/paste references between tasks using with_items and tasks using with_nested.
I can always write
action: …
with_nested:
but it feels clunky.
Has any of you encountered the same problem ?
with_nested is intended to be iteration over two loops, a nested loop.
with_nested over a single list doesn’t seem to make sense for me, you would just use “with_items”.
A nested loop over one list offends my computer science sensibilities, and may also indicate a typo from the user, I don’t think it should “just attempt to do something else” here.
Hello,
Sorry to insist here I thinks I understand the whole concept of nested loops 
A nested loop over one item satisfies my sensibilities because, in this specific case, I feel it plays the same role as “0 for the addition” or “1 for the multiplication”.
3 list case :
Loop
Loop
Loop
2 list case:
Loop
Loop
1 list case:
Loop
It doesn’t seem mis-behaved to be.
The main reason I am insisting here is because with_items and with_nested lead to totally different referencing schemes for the items.
with_items: {{ item }}
with_nested: {{ item.0 }}
which creates, in my viewpoint, non-necessary burden when you need to jump from a with_items scenario to a with_nested scenario and refactor a role.
Is there a way to do a with_items and still get the items as {{ item.0 }} ? maybe there is something I missed.
Thanks
I understand what you are saying and that you understand what you are saying, I’m just not sure it’s the best thing.
If someone types “with_nested” and only types one value, that’s kind of a typo 99 times out of 100.
The idea that “I need to make a source control change to another line” seems minor in the grand scheme of things.
you encounter user problems everyday a lot more than me so if it is more harmful than beneficial on a usability perspective let’s not do it !
I can very well live with
with_nested:
Let my explain a bit more my use case (which is not a simple source control problem).
Maybe I am the only one but tasks can rapidly become hard to read and hard to write because item.0, item.1,… are not natural (at least to me)
so what I do is define in defaults/main.yml a set of macro accessors, like, for instance :
m_config: “{{ bundle[item[0]].item[1] }}”
and then in the roles I can simply use everywhere looping permits, m_config.key1, m_config.key2, …
those “macro accessors” are very useful also when I need to re-organize the model of the datas because I usually simply have to change the macro definitions instead of going through the whole role.
My original post stemmed from the fact that with_items do not have the same references ({{ item }}) as with_nested ({{ item.0 }}) so the macro accessors cannot be shared between the with_items and with_nested cases.
I have a solution with the [“plug”], but the “one list” with_nested could have made this plug non-necessary.
Jerome
My general theory is when something is hard to explain or hard for me to process, it’s something hard, and we should avoid it.
That’s been keeping us going for a while.
The idea of “macro accessors” is kind of doing that to my brain right now 