Open meierw opened 5 years ago
Yeah, the yaml notation used here is very strange.
When you want to have
# have to use this yaml object notation to assign variables
# since the `rvm1_symlink_to` is in `vars` instead of `defaults`
- { role: rvm.ruby,
rvm1_rubies: [ruby-2.5.3],
rvm1_user: root,
rvm1_install_path: /usr/local/rvm,
rvm1_symlink_to: /bin,
rvm1_install_flags: --auto-dotfiles,
rvm1_gpg_key_server: 'hkp://p80.pool.sks-keyservers.net:80' }
it should look like this:
# have to use this yaml object notation to assign variables
# since the `rvm1_symlink_to` is in `vars` instead of `defaults`
- name: Configure servers with ruby support for single user
hosts: all
roles:
- role: rvm.ruby
tags: ruby
rvm1_rubies:
- ruby-2.3.1
rvm1_user: ubuntu
Using [] or {} is bad style, though [xxx] for a one element array in a one-liner should be ok,
I think it would be a good idea to move
rvm1_symlink_to
(and most likelyrvm1_symlink_binaries
andrvm1_symlink_bundler_binaries
) todefaults
instead ofvars
.The reasoning being - I recently had a use case where I needed to override this variable from
/usr/local/bin
to/bin
. And first I tried this approach:Which didn't work. The role still copied the symlinks to
/usr/local/bin
But afterward I tried one of the posted examples
And it worked.
Obviously Ansible parses these two notation methods differently.
But now I have a playbook, where most roles use the first notation, because I find it more neat (less commas and quotes) and this one role use a different notation. Also I have to leave a comment for other developers that this is intentional and they shouldn't try to "clean it up" and then break it.
Of course I could create my own task which creates the proper symlinks, but that means extra code for functionality that can already be handled by this role, and more clutter is added to the playbook.