Hello,
While it is sometimes indeed nice to have a complete folder to put all the task files or all the var files, most of the time, we only have one main file. That sometimes seems like a bit over-engineered and not very practical.
Would it be possible to look for a file named tasks.yml or vars.yml or handlers.yml before (resp.) tasks/main.yml, vars/main.yml or handlers/main.yml ?
That way, simple roles would look like:
- roles/
- role1/
- tasks.yml
- vars.yml
- role2/
- tasks/
- main.yml
- subtasks.yml
- vars.yml
Any opinion ?
A bit of a dead horse topic 
It’s engineered that way on purpose so that everyone’s roles follow the same structure and you don’t have to refactor them later when you move beyond this.
I don’t want to make this change and enable multiple code-paths to do this at this time.
I’m with Francois on this one. Many editors/IDEs group files by their filename only. It’s inconvenient when all kinds of different files are called main.yml (e.g. tasks/main.yml, handlers/main.yml, etc.). My IDE has several tabs titled ‘main.yml’ and I have to actually open several of them until I find the one I want to edit.
Also, the current imposed sub-directory structure brings no practical benefits. If you need to split your tasks into several yml files, the current structure does not help in any way. You still have to manually include the subtasks from your tasks/main.yml file. The same thing can be accomplished if the main tasks file was called tasks.yml, instead of tasks/main.yml. You could still place your subtasks inside a tasks/ subdirectory and include them from tasks.yml.
“Also, the current imposed sub-directory structure brings no practical benefits”
It is not so polite to claim something you do not understand has no practical benefits
This will not be changing guys,the structure is quite useful for when you want to break things up into multiple files of roles/handlers/templates/etc.
We listen to feedback from a lot of people, but part of what makes Ansible ansible is it’s not always a vote – else it would be a very inconsistent mess when everybody got what they wanted all of the time
Indeed, the directory structure is one of the great strengths of the ansible model.
However, with sublime text, the command i or p option for searching for files becomes useless since so many files are named main.yml
Since the role name is typically unique, what about allowing myrole/myrole.yml to be a default alias for main.yml?
k
It feels a little weird to change the hierarchy of the system based on the highlighting of a particular editor, but I’m not totally opposed. It’s a bit rough for me to accept though based on that we’re already doing about 3 stats for main, main.yml and main.yaml… how much more fuzzy would it get, etc? So I’m drawn.
/me campaigns for Visual SlickEdit from the late 90’s and it’s awesome tree-view to become more of a thing, where it doesn’t have that problem
effectively it would just be one more syscall / dirents for the role dir and several aliases/names for the listing there (tasks, vars, etc).
-k
I would also wonder what the precedence would be: what if you had
myrole.yml, tasks/myrole.yml and tasks/main.yml. Oh and we would have
to document that too. Oh dear, another precedence debate 
IMHO if an editor has difficulty with two files having the same
basename, then the problem is with the editor
I currently lay things out as follows
roles/myrole/tasks/main.yml
roles/myrole/tasks/myrole.yml
where main.yml is simply one line:
-include: myrole.yml tags=myrole
this largely get around the aforementioned issues (do you really need
that much editor support for a one line file?).
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd (w) +61 (0) 3 9008 5281
Suite 1415
401 Docklands Drive
Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer." -- IBM maintenance manual, 1925
Funny, I was just looking at these roles
https://github.com/al3x/sovereign/tree/master/roles/monitoring/tasks
and noticed the same convention
Besides changing the name of main.yml to <role>.yml I also like how it
tags the tasks with the name of the role.
-John
Tags can also be applied more easily at the role level if you wish:
roles:
- { role: rolename, tags: [ ‘rolename’, ‘dog’, ‘cat’ ] }
What if a failure to find main[.y[a]ml] led to a search for {{ role
}}[.y[a]ml]? Sort of a first_of style lookup. If they both exist,
main.yml takes precedence. If main.yml does not exist, in effect you get a
"default" main.yml that has an include: role.yml. In effect, what you are
already doing, just automagically.
My general rule is if something is weird to explain and makes the documentation confusing as a result, it’s usually something we want to avoid
I definitely get Michael’s point, and as a n00b editing a lot of main.yml files, I get Francois’s point. The following emacs hook lets me leave the file named main.yml, but renames the buffer on load to something more meaningful:
(add-hook 'find-file-hook
(lambda ()
(if (string-match “/roles/\([^/]+/[^/]+\)/main.yml$” (buffer-file-name))
(rename-buffer (match-string 1 (buffer-file-name)))) t))
I’m a DRY-kinda-guy so I don’t include /main.yml in the buffer name, but that’s easy to change in the above.
Rob