# \[Vote ended on 2025-05-20\] Collection requirements: dependencies-related changes

**URL:** <https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281>\
**Category:** Project Discussions\
**Tags:** resolved, community-wg, ee\
**Created:** [April 30, 2025, 7:24am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281 "2025-04-30T07:24:19Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\
**Post date:** [April 30, 2025, 7:24am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/1 "2025-04-30T07:24:19Z")

</div>

Hello,  
I’d like to suggest changes to the [Ansible community package collection requirements](https://docs.ansible.com/ansible/devel/community/collection_contributors/collection_requirements.html#meta-execution-environment-yml) wrt dependencies versions specification.

Currently we recommend (i.e. it’s a SHOULD) to include files with dependencies under `meta/`.  
The entries usually specify versions/ranges of the dependencies.

The issues imo occurs when a version is fixed, e.g. looks like `my_dependency == 1.0.0` or has a cap, e.g. `my_dependency <= 1.0.0`.  
In case we need to have more than one collection inside EE and one of them has a fixed/cap version and the other has a higher version of the same dependency, the build will fail. Example:

```auto
collection1_acme_dependency == 1.0.0
collection2_acme_dependency >= 2.0.0

```

Technically, you users can build multiple EEs to avoid the conflicts, but it’d probably require the following additional actions they’d have to do:

1. building multiple EEs
2. splitting roles to separate tasks done by those conflicting collections
3. run them with different EEs

Maybe not a frequent case, but doesn’t feel great anyway.

Please share your thoughts on the following questions:

1. Should we add a corresponding recommendation about not fixing,capping the versions, i.e. to merge [collection\_requirements: add requirements version specification recommendation to avoid conflicts when building EEs by Andersson007 · Pull Request #2585 · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/pull/2585) ?
2. Should we make it even a MUST (I’ll change the PR ^ if there’s support) ?

---

<div class="post-metadata">

**Author:** ![wayt](https://avatars.discourse-cdn.com/v4/letter/w/3be4f8/32.png) [@wayt](https://forum.ansible.com/u/wayt)\
**Post date:** [April 30, 2025, 5:36pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/2 "2025-04-30T17:36:44Z")

</div>

> [@Andersson007](#):
>
> 1. run them with different EEs
> 
> Maybe not a frequent case, but doesn’t feel great anyway.
> 
> Please share your thoughts on the following questions:
> 
> 1. Should we add a corresponding recommendation about not fixing,capping the versions, i.e.

I’d opt for keeping the ability to `>=` and `<=` and potentially dropping `==` into the `SHOULD NOT`.

If you mean to imply the `SHOULD NOT` could be overridden for those cases where pinning or capping versions is actually required then I’m also on board though.

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [April 30, 2025, 8:03pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/3 "2025-04-30T20:03:57Z")

</div>

`>=` is fine, IMO, and `==` is kind of evil (unless in very specific cases, like strong bundling of a collection to a Python package, for whatever reason). `<=` should be avoided, but is sometimes hard to / impossible.

I think `SHOULD NOT` (in the sense of [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119)) sounds good for `<=` and `==`. I would not use it for `>=` though. So basically what the PR proposes 🙂

---

<div class="post-metadata">

**Author:** ![shertel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/shertel/32/1241_2.png) [@shertel](https://forum.ansible.com/u/shertel)\
**Post date:** [May 1, 2025, 12:59pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/4 "2025-05-01T12:59:56Z")

</div>

I think it’s good as a general recommendation, and that it may be worth evaluating whether the handful of collections in ansible package that use `==` need to do so. I don’t see any using `<=`.

I don’t think it should be a MUST. There can be legitimate reasons to use `<=`, and I would prefer the build fails, than succeed but install incompatible dependencies.

---

<div class="post-metadata">

**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\
**Post date:** [May 2, 2025, 11:39am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/6 "2025-05-02T11:39:07Z")

</div>

Let’s keep the discussion open and start the vote late next week.  
Any other feedback would be appreciated, thanks

---

<div class="post-metadata">

**Author:** ![russoz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/russoz/32/127_2.png) [@russoz](https://forum.ansible.com/u/russoz)\
**Post date:** [May 3, 2025, 9:12am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/7 "2025-05-03T09:12:43Z")

</div>

Hi @Andersson007

I beg to differ a bit from the approach taken here. I don’t think we should _prescribe_ the use of (or lack thereof) specific operators. Instead I think we should try and explain the possible risks to the developers/users, so basically my point would be to remove the second bullet point in the PR and keep the third one (with some adjustments, of course, since it refers to things from the previous one).

Different strategies could be presented to the user:

- build separate EEs
- refrain from using fixed versions
- _\<space for more alternatives in the future\>_

I think that way users would have to think a little bit about their situation and find what works best for them, rather than trying to use a one-size-fits-all solution. Just my $0.02

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [May 3, 2025, 7:53pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/8 "2025-05-03T19:53:02Z")

</div>

It’s pretty painful if you cannot even run a role with one EE since two tasks in that role are modules from different collections that have incompatible EE requirements. Also the wording does not prohibit exceptions - but there shouldn’t be many, and they should have good reasons. (Maybe the wording can be clearer on that?)

---

<div class="post-metadata">

**Author:** ![russoz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/russoz/32/127_2.png) [@russoz](https://forum.ansible.com/u/russoz)\
**Post date:** [May 3, 2025, 11:31pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/9 "2025-05-03T23:31:15Z")

</div>

Maybe so, but then again, if we look hard enough I am sure we will find use cases in which not fixing the versions will be painful in different ways. But that’s besides the point. The wording I am suggesting also does not prohibit anything, but it takes a different angle: instead of say “do this, do not do that”, it says “these are the risks you may run into, and here are some strategies to mitigate them”. But the user has to take ownership of their problem/context and consciously make their own decision.

---

<div class="post-metadata">

**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\
**Post date:** [May 6, 2025, 6:33am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/10 "2025-05-06T06:33:09Z")

</div>

I incline to using `SHOULD` (which is also aligned with the must-should style we use across the requirements and catch the eye well) as in most of the cases, i believe, the dependency thing is a matter of code adjustment and maintainers responsibility, so the maintainers should do some work (especially relevant to vendors ones).  
It imo shouldn’t be a users problem and shouldn’t force them to build different EEs, split their roles as a result, run ansible multiple times, etc.  
A lot of “should”🙂

---

<div class="post-metadata">

**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\
**Post date:** [May 13, 2025, 8:58am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/11 "2025-05-13T08:58:23Z")

</div>

[@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) and the community, let’s vote (ends on May 20th 2025), so please do it ASAP

_Poll ([view on site](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/11))_

_Poll ([view on site](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/11))_

---

<div class="post-metadata">

**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\
**Post date:** [May 15, 2025, 11:44am UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/12 "2025-05-15T11:44:01Z")

</div>

@russoz valid point, though i would suggest keeping the prescription format to make it consistent with the rest of the document + it’s easier to spot `for us` (I’ll add it to the shorter checklist if it gets merged here) to inform maintainers about it: as i can see from my experience, many just not aware of this and don’t really read the requirements (unfortunately)…

UPDATE: Oops, noticed that I had already replied to russoz, sorry for repetition

---

<div class="post-metadata">

**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\
**Post date:** [May 21, 2025, 4:22pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/13 "2025-05-21T16:22:17Z")

</div>

Isn’t it time to close the vote…?

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [May 21, 2025, 5:56pm UTC](https://forum.ansible.com/t/vote-ended-on-2025-05-20-collection-requirements-dependencies-related-changes/42281/14 "2025-05-21T17:56:58Z")

</div>

I’ve closed the vote. There were 9 SC votes in favor of merging [[Needs Steering Committee vote] collection\_requirements: add requirements version specification recommendation to avoid conflicts when building EEs by Andersson007 · Pull Request #2585 · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/pull/2585), and none in opposition. There was no community vote casted. This means that we’re going to merge the PR and strengthen the EE dependency requirements.