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:
- myList
- [ "plug" ]
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
Le lundi 24 février 2014 20:58:36 UTC+1, Michael DeHaan a écrit :
>
> 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.
>
>
> On Mon, Feb 24, 2014 at 2:48 PM, Jerome Wagner <[email protected]<javascript:>
> > wrote:
>
>> 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
>>
>>
>>
>>
>> Le lundi 24 février 2014 14:07:47 UTC+1, Michael DeHaan a écrit :
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> On Mon, Feb 24, 2014 at 5:01 AM, Jerome Wagner <[email protected]> wrote:
>>>
>>>> Hello,
>>>>
>>>> I don't know if this is normal (feature?) or if it can be considered as
>>>> a bug that needs to be fixed :
>>>>
>>>> - name: my task
>>>> action: ...
>>>> with_nested:
>>>> - myList
>>>>
>>>> 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
>>>>
>>>> - name: my task
>>>> action: ...
>>>> with_nested:
>>>> - myList
>>>> - [ "" ]
>>>>
>>>> but it feels clunky.
>>>>
>>>> Has any of you encountered the same problem ?
>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Ansible Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>>
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/ansible-project/a3a7f704-24c4-4c5d-8af3-
>>>> 256716985036%40googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/b88a90d4-a736-40c5-8d56-ae52c88a8f92%40googlegroups.com
>> .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/c8487df9-1788-4851-b21d-895a4467297e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
