You can always use the --ignore-errors option too, so that the installation continues if you're not concerned about those failures.
On Fri, Sep 26, 2014 at 2:56 PM, <seasp...@gmail.com> wrote: > 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! > > > On Friday, September 26, 2014 12:46:48 PM UTC-7, James Cammarata wrote: >> >> 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. >> >> >> On Fri, Sep 26, 2014 at 11:46 AM, <seas...@gmail.com> wrote: >> >>> 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. >>> >>> >>> >>> On Friday, September 26, 2014 5:15:59 AM UTC-7, Michael DeHaan wrote: >>>> >>>> "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. >>>> >>>> >>>> >>>> >>>> On Fri, Sep 26, 2014 at 4:06 AM, <seas...@gmail.com> wrote: >>>> >>>>> 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: >>>>>> >>>>>> - role: apt >>>>>> >>>>>> apt_repo: >>>>>> >>>>>> - repo_url: "deb https://deb.nodesource.com/node {{ >>>>>>> ansible_distribution_release }} main" >>>>>> >>>>>> key_id: "68576280" >>>>>> >>>>>> key_url: "https://deb.nodesource.com/gp >>>>>>> gkey/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. >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Ansible Project" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to ansible-proje...@googlegroups.com. >>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/ansible-project/82fca86e-3e05-40e9-968d-370b7a613e45% >>>>> 40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ansible-project/82fca86e-3e05-40e9-968d-370b7a613e45%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to ansible-proje...@googlegroups.com. >>> To post to this group, send email to ansible...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/ansible-project/9a0ae95a-5a6a-4f95-9534- >>> 735c2b80ec7c%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/9a0ae95a-5a6a-4f95-9534-735c2b80ec7c%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/5023d20e-ac7c-4056-b807-69ecfa3675b3%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/5023d20e-ac7c-4056-b807-69ecfa3675b3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAMFyvFigHVf%3DmBaXreonMAzHKGsx9p_dUWxxkKscLAJpj_g_Nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
