In theory, yes we could, however that wouldn't buy us much. The problem is that, if the include uses a variable for the file name or loop, that variable may change of the execution of the playbook. This is particularly common for loops, where some previously registered result is used for the loop variable to an include.
James Cammarata Ansible Lead/Sr. Principal Software Engineer Ansible by Red Hat twitter: @thejimic, github: jimi-c On Tue, Mar 15, 2016 at 1:03 PM, Timothy Appnel <[email protected]> wrote: > @jimi-c: Is it possible to evaluate static includes after the setup module > runs to gathering facts? The most common use pattern I see in users plays > and roles are dynamic includes that define the filename based on a fact > like ansible_os_family. Collecting the fact before evaluating includes > would make things even more seamless for users. > > Timothy Appnel > Principal Architect > Ansible by Red Hat > > +1 718.404.6429 | <+1+718.404.6429> ansible.com <https://www.ansible.com/> > > > GitHub: tima <https://www.github.com/tima> > > Twitter: @appnelgroup <https://www.twitter.com/@appnelgroup> > > On Tue, Mar 15, 2016 at 11:32 AM, James Cammarata <[email protected]> > wrote: > >> On Tue, Mar 15, 2016 at 11:03 AM, Strahinja Kustudić < >> [email protected]> wrote: >> >>> So basically now simple includes without any loops or variables in file >>> name will be static by default? That is great news, since most of the >>> includes are like that and it makes them at least backward compatible with >>> 1.x. >>> >>> Could anyone tell me what exactly is the difference between: >>> >>> - include: "{{ some_var }}.yml" >>> static: yes >>> >>> >> In this case, the include would be processed at playbook parsing time, >> meaning there is no inventory. As such, `some_var` would have to be >> available in playbook vars (vars/vars_files/role vars and defaults), or >> extra vars. Tasks and all related info would be available to things like >> --star-at-task, --list-tags, and --list-tasks. >> >> >> >>> >>> and >>> >>> - include: "{{ some_var }}.yml" >>> static: no >>> >>> Does it mean for static: yes that some_var would need to be defined >>> statically as a var, and for static: no some_var could be defined >>> during play execution, e.g. set_fact: some_var=something. >>> >>> >> In this case, the include would not be processed until that task was hit >> at execution time, meaning `some_var` could come from any and all available >> variable sources in ansible. Nothing about the tasks in this file would be >> known at compile time, and as such that information would not be available >> for the CLI switches mentioned above. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/CAMFyvFiSXAEYUkZy7jVGAbbyN6ho7GXnHij79%3D3OjgKGMz4ufA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
