# set\_fact support for list of dictionaries? **URL:** \ **Category:** Ansible Project\ **Created:** [July 17, 2014, 5:16pm UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697 "2014-07-17T17:16:28Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![E.C\_Raymond](https://avatars.discourse-cdn.com/v4/letter/e/e19adc/32.png) [@E.C\_Raymond](https://forum.ansible.com/u/E.C_Raymond)\ **Post date:** [July 17, 2014, 5:16pm UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/1 "2014-07-17T17:16:28Z")
What is the status on complex data storage for set\_fact? It seems like its not quite possible yet when I have tried multiple methods. - name: testing set\_fact: vms=“[‘{ {{ item.item }}: {{ item.stdout.strip(’\n’) }} }']” with\_items: - “{{ hostips }}” I found these links that got me close enough, but I am guessing that this is not yet supported. [https://groups.google.com/forum/#!topic/ansible-project/cPbCD6R9TnE](https://groups.google.com/forum/#!topic/ansible-project/cPbCD6R9TnE) [http://stackoverflow.com/questions/23507589/is-it-possible-to-set-a-fact-of-an-array-in-ansible](http://stackoverflow.com/questions/23507589/is-it-possible-to-set-a-fact-of-an-array-in-ansible) Thanks. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [July 18, 2014, 1:37am UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/2 "2014-07-18T01:37:46Z")
You are passing it a string above. Don’t do that. Try this: - set\_fact: x: ---
**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\ **Post date:** [July 18, 2014, 6:49am UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/3 "2014-07-18T06:49:21Z")
I have an outstanding PR for that: [https://github.com/ansible/ansible/pull/8019](https://github.com/ansible/ansible/pull/8019) ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [July 18, 2014, 11:42am UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/4 "2014-07-18T11:42:03Z")
Oh nice. This isn’t related to your commit - I’m starting to worry a bit about continual buildup of inline code cruft in Runner - so we may hold off on this a little bit until we can refactor things a bit to find a good place for things like this. This is a hard thing to stress on submissions, but over time, things build up. In general, making some smaller functions and having the runner code call them would be a good idea. ---
**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\ **Post date:** [July 18, 2014, 12:15pm UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/5 "2014-07-18T12:15:29Z")
​Agreed. Maybe the way on how to refactor this can be discussed on -devel? ​ ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [July 18, 2014, 12:29pm UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/6 "2014-07-18T12:29:22Z")
Yeah it’s more of a devel topic, but since we’ve started the thread, I’ll share a bit. I already have several things in mind - but they are hard to detail over text for me for an extent. While I generally want to make this project as maximally open to code review as possible, with some exception, reviewing outside refactorings is one of those things that I want to audit like a razor and I need to be really really really careful, so in general, unless discussed first, we /don’t/ take outside refactoring requests because they are too dangerous. Some contributions are really easy - especially new things - to take in - and we have increasing test and integration coverage - though subtlety still lurks in places. So just saying that so someone doesn’t try - refactoring changes in certain places can also invalidate a lot of pull requests, though Runner is not one of those things that are in major flux. It’s really something James and I have some plans for, and it’s going to start being a major priority over the coming releases or two. It’s also a bit more of a philosophy - when some code is touched, clean it up a bit and leave it more organized than it was originally. I’ve also taken a few (aborted) stabs in this direction, so I have a feeling of where it needs to go. It will probably start with just breaking more things into smaller functions, for starters, but eventually I want to see task objects passed into Runner directly. For new folk, I do want to stress though that the tree is in good shape - we just want to make it even easier to contribute to, and easier to stretch in new directions, without making it harder to follow. ---
**Author:** ![Brian\_Jones1](https://avatars.discourse-cdn.com/v4/letter/b/91b2a8/32.png) [@Brian\_Jones1](https://forum.ansible.com/u/Brian_Jones1)\ **Post date:** [August 26, 2014, 9:24pm UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/7 "2014-08-26T21:24:55Z")
Is this related to this odd set\_fact behavior I’m encountering with ansible 1.7.1? [http://pastebin.com/iBwfp7gA](http://pastebin.com/iBwfp7gA) I don’t want to use foo.stdout\_lines because I intend to sometimes pass in foo via -e, hence why I’m trying to define a fact. Brian ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 26, 2014, 11:01pm UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/8 "2014-08-26T23:01:56Z")
You’re replying to an old thread from July which was a little long, so I’m not sure what this inquiry was about. “Is this related to this odd set\_fact behavior I’m encountering with ansible 1.7.1?” Could use some help clarifying what the pronoun “this” refers to. Sorry, internets make this hard sometime 🙂 ---
**Author:** ![Brian\_Jones1](https://avatars.discourse-cdn.com/v4/letter/b/91b2a8/32.png) [@Brian\_Jones1](https://forum.ansible.com/u/Brian_Jones1)\ **Post date:** [August 27, 2014, 12:54am UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/9 "2014-08-27T00:54:15Z")
I found a probably even older thread with a solution to my particular issue, demonstrated by the pastebin from my original message. This doesn’t work… - set\_fact: directories=“{{ directories\_output.stdout\_lines }}” This does work… - set\_fact: directories: “{{ directories\_output.stdout\_lines }}” That’s pretty screwy. By work I mean, usable as an array in a Jinja2 template in a typical for loop. Brian ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 27, 2014, 1:08am UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/10 "2014-08-27T01:08:45Z")
It’s not the least bit screwy. If you are doing key=value stuff all on one line, Ansible doesn’t know what is a string or not. Jinja2 templating happens before values are past. You are correct in that the long form set\_fact does hold types nicely, and is what you want. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 27, 2014, 1:09am UTC](https://forum.ansible.com/t/set-fact-support-for-list-of-dictionaries/15697/11 "2014-08-27T01:09:22Z")
Also you actually mean this (note spacing): - set\_fact: directories: “{{ directories\_output.stdout\_lines }}” This is because directories is not a parameter to the task, it’s passed to the “set\_fact” module.