-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
meta/requirements.yml #57
Comments
👍 for a standard location for AWX/Tower to find Galaxy requirements (currently supports only |
@cchurch was thinking of keeping 'role requirements' there .. but now i'm favoring |
Would really like to see this added. Current installing of dependencies by Any news about this? It should be an easy thing to implement, but it would make it a lot easier to install dependent roles. I would even be willing to make a PR for this :) |
@kustodian we are currently discussing this both in IRC meetings and internally as there are other plans for installing galaxy content that could be affected by this and/or duplicate efforts. I hope i can give you an answer soon. In any case I think the initial scope should be 'role only' we can expand (or not) to play and other levels later. |
@bcoca that's great news and just adding it to roles for now is the most important. |
Hi @kustodian, as @bcoca mentioned a lot is in flight at the moment. We're focusing a lot of our efforts on this and other areas of Galaxy. Stay tuned for more info in the coming months! |
May I join the discussion somewhere? |
@kustodian there's logs of IRC meetings you might want to check: https://github.com/ansible/community/issues?utf8=%E2%9C%93&q=is%3Aissue+Public+Ansible+Project+Meeting+Agenda It was mentioned at least @ ansible/community#329 |
any updates? |
I've already tried to solve the dependency problem without knowing about this proposal and would still like to solve this since it forces users to use external/homebrew tools but I don't want to work for nothing. Can one of you tell me the likeliness of an implementation of this proposal being merged in 2020 if I were to do it? |
@DaazKu Without seeing an implementation of the feature, I cannot say whether or not it would be accepted. Also depending on when it is submitted, when the review is complete, and when we would decide to merge, it may or not make it into the 2.10 release. Everyone runs the risk of doing work, and it not being accepted, this happens to even @bcoca and myself. |
👋 We have started a project called https://github.com/ansible/ansible-builder Let me call attention specifically to the section "Collection Execution Environment Dependencies" in the README.md. The form of dependency specification it accepts is built from existing common practices among collections, and there have been many collections that required no modification. I want to start the conversation about how this can be the solution for some of the problems discussed here. |
We do now support |
@AlanCoding - I think #158 may be more relevant to the Execution Environment dependencies since that deals more with the module deps :) — I think I missed that in my earlier searches. |
@sivel I have found ansible/ansible#68288 |
Closing. |
How can meta/requirements.yml be used to install collections?
I get ERROR! Expected role dependencies to be a list. |
this proposal was not implemented, the alternative is what the link above documents |
Sorry to nag, which document do you mean? Because there it states meta/requirement.yml is implemented from 2.10, but it doesnt state which version of the requirements file (with roles and collection keywords or as simple list) |
The implementation that was made at the time, for roles, only works for roles. |
Nor will it be. There is NO planned activity to allow roles to list collections they depend on that will allow them to be automatically installed, nor a collection to list roles they depend on. |
you can have a requirements.yml (not in meta/) that holds both dependencies but both will not be automatically installed, only the same type as the current object installed, it requires a 2nd run of |
Ok but should the meta folder describe the role? How should somebody who wants to use a role from galaxy know what the collection requirements for this role are? Sorry to reopen this "old" proposal, perhaps I miss something here. |
A stand alone role should generally not have collection requirements. Migrate that role into a collection, and then it can have requirements on another collection. Otherwise, you are basically going to just have to add instructions to the readme that explain the need to install additional dependencies. |
My solution to this problem right now is to tell people using roles to generally try to install As time goes on, and more roles are built directly into collections, or roles are slowly upgraded to use FQCNs and such, this won't be an issue anymore, but there will likely still be a long transition period, and the easiest answer (and what I do) is to just install the full community edition since 99.9% of the modules standalone roles on Galaxy use will be part of that for a long time to come. |
Our use case are windows targets, so in almost every role we write we require ansible.windows and community.windows. The automatic installation is one part of the problem, the otherside is documentation. So this also about having the documentation in a structured format. I sure could simply put a collections.yml in /meta but I thought there would be an ansible way to do this. |
Also as an addition, even if we would use collections, we would either need to have single collection for each role, because I would also like to track which role needs / uses which collection, so If we would put multiple roles into one collection we still would lose the information which role uses which collection. So apart from the automatic installation dependency management and tracking is not solvable with how its implemented currently. |
Proposal: standard location for requirements
Author: Brian Coca (@bcoca)
Date: 2017/03/33
Motivation
Plays that use 3rd party roles have to manually deal with requirements, also roles cannot easily provide their requirements making a requirement chain hard to follow.
Problems
Easy installation of requirements for a playbook (currently just roles).
Solution proposal
New 'standard' file: meta/requirements.yml, that can exist at either role or adjacent to play (role already has meta/ dir).
The file structure would be the same as current role requirements.yml, as it now lives in a 'predictable' place we can chain then when doing role installs.
Related
This would make autoinstall a lot easier #7
possibly related to/subset of ansible-config #35
The text was updated successfully, but these errors were encountered: