This is caused by the path_dwim_relative function. When with_first_found is used within a role, the role's path is passed to path_dwim_relative, which (correctly) identifies it as a role and appends the role's tasks/ directory to the search list. This means that tasks/ is essentially searched in every iteration. The code is here.

I don't really know why this behaviour is desirable so I don't know how I would go about patching this bug. It's possible that the 'patch' is really to let path_dwim_relative handle the list of places to search (instead of the list that's iterated through here), and document the order of places that with_first_found will search by default.

this is because first_found looks at 'all' dirs no matter what the task is, it should be more discriminatory and use 'vars' in this case and not 'files' nor 'templates' which find the match in 'tasks' before even trying 'vars'

Ran into this problem today aswell.

please confirm that merge above fixes this

An exception occurred during task execution. The full traceback is:
Traceback (most recent call last):
File "/Library/Python/2.7/site-packages/ansible-2.2.0-py2.7.egg/ansible/executor/task_executor.py", line 92, in run
item_results = self._run_loop(items)
File "/Library/Python/2.7/site-packages/ansible-2.2.0-py2.7.egg/ansible/executor/task_executor.py", line 259, in _run_loop
res = self._execute(variables=task_vars)
File "/Library/Python/2.7/site-packages/ansible-2.2.0-py2.7.egg/ansible/executor/task_executor.py", line 454, in _execute
result = self._handler.run(task_vars=variables)
File "/Library/Python/2.7/site-packages/ansible-2.2.0-py2.7.egg/ansible/plugins/action/include_vars.py", line 41, in run
source = self._find_needle('vars', source)
File "/Library/Python/2.7/site-packages/ansible-2.2.0-py2.7.egg/ansible/plugins/action/init.py", line 843, in _find_needle
result = self._loader.path_dwim_relative_stack(path_stack, dirname, needle)
File "/Library/Python/2.7/site-packages/ansible-2.2.0-py2.7.egg/ansible/parsing/dataloader.py", line 284, in path_dwim_relative_stack
if source.startswith('~') or source.startswith(os.path.sep):
AttributeError: 'NoneType' object has no attribute 'startswith'

@eb4x that should only happen if you search for empty or null string (fixing this path now).
@JamesBelchamber I'm going to assume everything is working for you and will close the ticket unless you tell me otherwise

I've created a minimal test case you can pull, https://github.com/eb4x/ansible-bug.git

TASK [example : include_vars]
failed: localhost => {"failed": true, "item": "ansible-bug/roles/example/tasks/RedHat.yml", "message": "ansible-bug/roles/example/tasks/RedHat.yml must be stored as a dictionary/hash"}

Which makes it seem like nothing has really changed. include_vars is still pulling from tasks instead of vars directory first.

so it worked for me cause of 'test bias', now it should work for everyone via ce282e9.

Sorry to pry but:

1. I keep running into problems like this where I have to leave workarounds in my roles to actual ansible bugs. Am I using too recent of a version in Fedora? Is this issue present in all lesser versions to 2.1.1 as well?
2. What exactly is the best practice way to workaround this? Understand that my mentality is that while I could patch my local copy of ansible, I want my role to be compatible to other unsuspecting users.
   • It seemed the most logical and elegant thing was to not have files with the same name, so I decided to go with {{ ansible_os_family }}.yml for vars, and the tasks are prefixed with t_{{ ansible_os_family }}.yml and are named such in their respective folders. And then I left a comment referencing this issue. Is that correct?
3. Even though this is now fixed, it's worth mentioning that the error message wasn't helpful until I came across this bug. I didn't catch on until I looked closely and saw that include_vars: was complaining about a file in tasks/ versus vars/