I believe that was explained. The "magic" as you call it, only affects jinja2 templating, because historically jinja2 could only ever generate strings, but the intention was often to generate python data types.
We don't do that for things that don't go through templating, because the author can define it explicitly as the type they want. On Wed, Jan 5, 2022 at 10:24 AM Vladimir Botka <[email protected]> wrote: > On Wed, 5 Jan 2022 10:09:45 -0600 > Matt Martz <[email protected]> wrote: > > > > For example, given "val1: foo" > > > > > > - set_fact: > > > _var1: | > > > {"key1": "{{ val1 }}"} > > > _var2: | > > > {"key1": "foo"} > > > - debug: > > > var: _var1|type_debug > > > - debug: > > > var: _var2|type_debug > > > > > > gives > > > > > > _var1|type_debug: dict > > > _var2|type_debug: AnsibleUnicode > > > > > > *_var1* expands to a dictionary but *_var2* expands to a string. Is it > > > a feature or a bug? > > > b. Because jinja2 has historically only had the ability to template > > strings, we do some magic to try and convert strings that look like > python > > data structures to python data structures > > Why don't you try this magic consistently both on jinja2 and > non-jinja2 expressions? > > Thank you, > > -- > Vladimir Botka > -- Matt Martz @sivel sivel.net -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAD8N0v-q4vTLg4Kra22rWhvPHCXeCC5fvUd6jR9r6wtV3%3Dx8Bw%40mail.gmail.com.
