@decause likes 24h clocks

[decause]

https://github.com/ralphbean/lightsaber/blob/6b45251fe8e0cde41b31cc0ec3184125c4d0ac8e/roles/gnome/user/vars/main.yml#L6

What might be the right way to make this part of my laptop.yaml?

[abadger]

You want to have all the settings here but change one of the variables, correct?

What do you think of this solution:

$ ls vars
main.yml
decause.yml
default.yml

$ head tasks/main.yml
# Allow overriding the variables set in main.yml
- include_vars: "{{ item }}"
  with_first_found:
    - files:
      - "{{ username }}.yml"
      - "default.yml"
    - paths: "../vars"

main.yml is the same as it is now.

default.yml is an empty file in this example. It's just there so ansible won't error if this user doesn't override anything in main.yml.

decause.yml contains a copy of standard_keyboard_gsettings with clock-format set to 24h instead of 12h. Unfortunately at this time I can't think of a way in ansible to override just a single element of the dict. You'll have to copy the dict with the field changed. [maybe in the future set theory operations for dicts will allow this, though].

Doing things this way keeps information about the role together but information about decause is spread out. It requires the role's tasks/main.yml to have support for the override.

I think an alternative would be to pass the variable in as a parameter to the role. That would allow you to keep the information about decause associated with the decause group but it would mean that you're defining information about specific roles in isolation from the role. If the role changes its variable names, for instance, then you might not realize that the decause group_vars needed to be updated as well.

I know that many roles on galaxy.ansible.com follow the latter model because they think of themselves as functions that the user adds to their local playbooks and then calls. Not sure which model we want to follow in this repo.

[ralphbean]

Thanks for looking at this Toshio.

I think an alternative would be to pass the variable in as a parameter to the role

I think I like this the most.

I know that many roles on galaxy.ansible.com [do this] think of themselves as functions that the user adds to their local playbooks and then calls.

That's probably why it's attractive to me :)

In more complex repos like the Fedora Infrastructure one, leveraging group vars in roles (instead of explicitly passing them in) seems attractive because of how you can reference the vars of one group from hosts of another (i.e., you could have a nagios template that lists all the hosts in your inventory and knows where to check them and what special checks to run just based on their group vars).

But for simpler isolated-host cases like lightsaber handles, passing the vars in as "explicit arguments" seems cleaner and hopefully easier to read and understand.