# Exporting variables as host facts **URL:** \ **Category:** Ansible Project\ **Created:** [April 13, 2013, 12:52am UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676 "2013-04-13T00:52:27Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [April 13, 2013, 12:52am UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/1 "2013-04-13T00:52:27Z")
Ok, in the old days Ansible would have all variables defined in a playbook in the global scope. At some point this was deemed non-intentional and we limited it to the local scope of the play instead. But that means that prompt\_vars too are bound only to the local scope, and one cannot easily define variables in a play to the global scope, unless you mock around with command, echo and register. Some people have asked for such a 'variable' module before, I called mine 'export'. The shortest module ever ! You can find it in the ansible-provisioning repository at:      [https://github.com/ansible-provisioning/ansible-provisioning](https://github.com/ansible-provisioning/ansible-provisioning) How does it work: ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 13, 2013, 1:28am UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/2 "2013-04-13T01:28:19Z")
Can you send me a pull request and maybe rename this to “set\_global” ? I think we also want some nice “set\_local” too, though I also agree this is basically register, folks have been wanting a way to save {{ foo.upper() }} and things like that in 1.2 to variables, occasionally. ---
**Author:** ![Antonio\_Messina](https://avatars.discourse-cdn.com/v4/letter/a/9de053/32.png) [@Antonio\_Messina](https://forum.ansible.com/u/Antonio_Messina)\ **Post date:** [April 13, 2013, 10:28am UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/3 "2013-04-13T10:28:18Z")
This is very interesting. I actually stumbled upon a problem yesterday that this module would have fixed 🙂 .a. ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [April 14, 2013, 8:57pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/4 "2013-04-14T20:57:47Z")
I think naming is important and I really don't like 'set\_global' and 'set\_local' as names. Not that I am emotionally attached to 'export' either. Can we do better ? ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 14, 2013, 9:13pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/5 "2013-04-14T21:13:23Z")
Asking this seriously, better how? I don’t really like “export” (that already means something in Unix land, and lots of other things elsewhere), and it does set a global, doesn’t it? ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [April 14, 2013, 10:21pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/6 "2013-04-14T22:21:59Z")
Why not just use local vs global ? It can't be more explicit (as we like it) without the redundancy. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 14, 2013, 10:24pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/7 "2013-04-14T22:24:22Z")
Sorry, as I mentioned earlier my brain was recovering from being sick this weekend. Just clicked that you are setting locally because you are returning facts. That’s great, let’s just call it ‘set\_local’ then? ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 14, 2013, 10:27pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/8 "2013-04-14T22:27:00Z")
Actually, I’d probably just go with “set” 🙂 ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [April 14, 2013, 10:43pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/9 "2013-04-14T22:43:52Z")
Less is more ! So we go for "set" and "global", right ? I'll do the PR tomorrow, need sleep now... ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 14, 2013, 11:55pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/10 "2013-04-14T23:55:14Z")
Sure! (s and g! No, wait!) Thanks! Sleep is good. Except when I design systems management software in my sleep. I’m getting close to having a working sleep-mode Python compiler. You don’t want to know 🙂 ---
**Author:** ![Antonio\_Messina](https://avatars.discourse-cdn.com/v4/letter/a/9de053/32.png) [@Antonio\_Messina](https://forum.ansible.com/u/Antonio_Messina)\ **Post date:** [April 15, 2013, 6:18am UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/11 "2013-04-15T06:18:05Z")
"set" is a bit vague IMHO, a newbie would wonder \*what\* is actually set. What about "vars"? It recalls the "vars:" section, it should be more straightforward. especially for new users. .a. ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [April 15, 2013, 12:32pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/12 "2013-04-15T12:32:41Z")
Problem with vars is that people may think they can add variables just like the "vars:" section in the playbook, while this is in fact an action in a task. Becomes very confusing very quickly... ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 15, 2013, 12:47pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/13 "2013-04-15T12:47:31Z")
don’t think there’s much you can set in any system that is not a variable. Jinja2 has a set keyword, for instance. ---
**Author:** ![GW1](https://avatars.discourse-cdn.com/v4/letter/g/c89c15/32.png) [@GW1](https://forum.ansible.com/u/GW1)\ **Post date:** [April 15, 2013, 3:49pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/14 "2013-04-15T15:49:48Z")
Hi, What about “register”? And maybe making the module behave as close to the other meaning of “register” keyword, that it would not cause too many confusions? Otherwise “set” makes sense. A weird idea that probably shouldn’t be implemented would also be to create a module to just execute arbitrary Jinja2 code, eg “eval” or “jinja2”: eval: “{{ set foo = bar }}” Greetings, gw ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 15, 2013, 8:14pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/15 "2013-04-15T20:14:07Z")
You can already use the proposed set with Jinja2, there is no need for a new eval. ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [April 15, 2013, 9:23pm UTC](https://forum.ansible.com/t/exporting-variables-as-host-facts/12676/16 "2013-04-15T21:23:48Z")
Namespace conflict. How would Ansible make the distinction between:   - register: foo=bar   - user: name="foo"     register: bar It reads like:    - action: register foo=bar    - action: user name="foo"      register: bar That's why we have to be very careful not to name modules after reserved words, and not introduce new statements named after module names. 'user' in itself is already quite confusing as it's used in plays and as a module name in tasks. As a tutor I always advise to use "action:" and not "module:". Go for explicit statements, not brevity !