Awx: Support unified requirements.yml file roles/collections

[AlanCoding]

ISSUE TYPE

• Feature Idea

SUMMARY

See: https://github.com/ansible/ansible/pull/67843

Right now, we install files

roles/requirements.yml
collections/requirements.yml

The first will install with ansible-galaxy install, the second will install with ansible-galaxy collection install.

That PR will allow installing _both types_ with ansible-galaxy install.

Assuming this is the final form that merges (there seems little doubt), none of this will make a lot of sense. It doesn't make sense to allow putting collection requirements in the roles folder.

Tentative idea of how to react to this:

• Depending on Ansible version, switch to ansible-galaxy role install roles/requirements.yml
• Look for a unified requirements.yml file in a 3rd, new, yet-to-be-decided location

[geerlingguy]

For a unified file, why not requirements.yml in the root of the project folder?

[wenottingham]

Because that's not where anyone has put it before. I would not want to invent a new thing, especially since download-at-execution is a pardigm we'd like to move away from.

[geerlingguy]

Because that's not where anyone has put it before.

That's where I've always put it—for any kind of project where you have to manage dependencies (node.js package.json, php composer.json, ruby Gemfile, python pip requirements.txt, rust cargo.toml, etc.), the standard seems to be "put the list of dependencies/requirements in a file in the project root, and when you are going to build or run the project, run the command using that root file.

I don't understand the reasoning behind splitting the requirements in two files (current behavior) or stashing an Ansible requirements file in some subdirectory... I think if anything, following the precedent of other software ecosystems makes for the least end-user frustration, when they come in and realize they have to do special (and different) things to structure their projects for Ansible Tower/AWX.

[geerlingguy]

download-at-execution is a pardigm we'd like to move away from

I dislike that too; for most of my Ansible projects I just commit all the dependencies to the codebase so I don't have to rely on galaxy (or AH) to be up and reachable for all the role/collection installs.

For many systems, like composer, npm, etc., though, the install process is much quicker and the dependency manager can handle updating dependencies (e.g. if the version you have locally doesn't match the version in the requirements file). Unfortunately, Ansible's ansible-galaxy command can't quite do that currently, and there's no concept of a 'lock' or 'freeze' file either (which is why I opened https://github.com/ansible/galaxy/issues/1358).

[wenottingham]

I think if anything, following the precedent of other software ecosystems makes for the least end-user frustration, when they come in and realize they have to do special (and different) things to structure their projects for Ansible Tower/AWX.

The reason I refer to this as additive is that we have already shipped releases that pull from roles/requirements.yml and collections/requirements.yml. So any place else we look is net new, and we'd still have to support existing locations.

[geerlingguy]

@wenottingham - The one quibble I have with that is I'm presuming collections use is currently minimal (though I could be totally wrong there), so it's not a huge problem to deprecate that current pathing, and move to something different. Once Ansible (ACD/Platform/etc.) 2.10 is released a lot more people will be using collections from that point forward.

[wenottingham]

Yes, but in that case we wouldn't be parsing this file at runtime anyway.

[AlanCoding]

Ansible core PR merged

[sbaerlocher]

I would support it very much, as already mentioned by @geerlingguy if it would be possible to put a requirements.yml with roles and collections in root directory.

If it is desired I would create a PR.

[AlanCoding]

See the pattern started in https://github.com/ansible/awx/pull/8312

[sbaerlocher]

@AlanCoding This doesn't cover exactly that, I meant the requirements.yml is in the project root, I made PR #8318 for it.

[AlanCoding]

I link that because the way the playbook operates is changing to accommodate the yml/yaml extensions. Merging that with what you're starting in #8318 is going have have to reconcile these patterns.

[sbaerlocher]

Now I have adapted it like in PR #8312 .