Hi there,
I’m currently using the in-development 1.8 version of Ansible to get access to the enhanced requirements.yml features for the ansible-galaxy command line tool. I’m using it to install roles from GitHub with the appropriate config, and for the most part everything is working OK. However, a few times I’ve ran into issues working with roles I’ve created that have meta/main.yml dependencies specified.
Until about an hour ago, when setting up a test case to replicate the problem I am running into, I wasn’t aware of the comment that is generated in meta/main.yml when you do ansible-galaxy init – " # List your role dependencies here, one per line. Only dependencies available via galaxy should be listed here. Be sure to remove the ‘’ above if you add dependencies to this list."
Is that a hard rule, that you can’t add dependencies via the meta/main.yml workflow? I’ve actually been structuring some of my roles around the functionality of adding a dependency in another role and specifying variables, unaware that meta/main.yml dependencies are only for galaxy resolution. I’d just like some clarification on this, and maybe thoughts around an alternative workflow if I shouldn’t be using role dependencies this way.
The problem I encountered before discovering this was that ansible-galaxy would fail to install roles from the requirements.yml if they had a meta/main.yml dependency specified that wasn’t from galaxy – I guess I had been relying on what was on the local filesystem and what the tool downloaded.
An example of how some of my dependencies are being used (this is from a role to install nodejs, calling another role I’ve created to manage apt repos):
dependencies:
apt_repo:
key_id: “68576280”
key_url: “https://deb.nodesource.com/gpgkey/nodesource.gpg.key”
Let me know if I wasn’t clear enough or you have any questions. Any feedback would be greatly appreciated.
Thanks for your time.
"Is that a hard rule, that you can’t add dependencies via the meta/main.yml workflow? "
Right, That’s the only way you add dependencies.
What that was saying is roles on galaxy should have all their dependencies on galaxy, else the role should not be on galaxy.
Why? Because it’s totally wrong to be sharing content with people they can’t use 
Galaxy is not a place for personal private content, it’s a place to share content with other OSS users.
Hi Michael,
Thanks for your response.
Absolutely, I understand that Galaxy is not a private content store – this is exactly what I’m trying to avoid. I think there might be confusion when I say galaxy the tool vs galaxy the service.
I’m using ansible-galaxy as a role depsolver to download roles from private GitHub repositories, and occasionally from Galaxy (the service). Because Ansible itself seems to understand meta/main.yml in that it’ll include any dependencies listed there in a run, it seemed like it could be used for non-galaxy roles (ie private roles). Since this happens automatically within Ansible, it is very useful to include both public and private roles in the meta directory.
If it isn’t intended to use the meta directory to list both open source and internal deps, is there a functionally equivalent alternative?
Thanks.
Role dependencies that are not on Galaxy can be listed in the metadata along with roles that are - however as Michael said, such roles should not be shared via Galaxy since other users won’t have access to them, and the role will therefore not work.
If you’re writing a role for personal use however, you can list any role dependencies there that you wish. The commented generated by the CLI tool when using “init” to create a new role directly simply assumes that the role will be uploaded to Galaxy, so really the comment should read “# If you’re going to upload this role to Galaxy, be sure to list only dependencies that are also available via Galaxy”.
Hope that clears things up.
Great, thanks for the clarification!
It looks like I am running into a bug then. If my requirements.yml includes a role and that dependency itself has further non-galaxy dependencies (say from GitHub for example), ansible-galaxy install will fail to install the first level dependency and error out. I’m not expecting it to resolve transitive dependencies (though that would be nice). I’ll see if I can create an example demo of this and then submit an issue.
Thanks again!
You can always use the --ignore-errors option too, so that the installation continues if you’re not concerned about those failures.
Yeah so we have this is in the bug tracker now for Ansible I think, so should be being tracked.
https://github.com/ansible/ansible/issues/9173
If not, please make sure there’s a new bug.
As per that issue (https://github.com/ansible/ansible/issues/9173), I am still experiencing problems despite the committed changes. I’ve removed the sample repositories linked to in that issue since all that is really needed to replicate this issue is the requirements.yaml file.
Given the following gist: https://gist.github.com/cspicer/7c3c37eaf8eff386f9ce
ansible-galaxy install will still fail using:
$ ansible-galaxy install -r requirements.yml
Traceback (most recent call last):
File “/Users/spicy/Development/oss/ansible/bin/ansible-galaxy”, line 901, in
main()
File “/Users/spicy/Development/oss/ansible/bin/ansible-galaxy”, line 895, in main
fn(args, options, parser)
File “/Users/spicy/Development/oss/ansible/bin/ansible-galaxy”, line 711, in execute_install
roles_left = map(ansible.utils.role_yaml_parse, yaml.safe_load(f))
File “/Users/spicy/Development/oss/ansible/lib/ansible/utils/init.py”, line 432, in role_yaml_parse
if ‘github.com’ in role[“src”] and ‘http’ in role[“src”] and ‘+’ not in role[“src”] and not role[“src”].endswith(‘.tar.gz’):
TypeError: string indices must be integers, not str
Not sure if this is my syntax that is an issue, or if this is still a bug. Should I file a new bug?
Thanks!