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:
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.
>= 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) sounds good for <= and ==. I would not use it for >= though. So basically what the PR proposes
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.
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
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?)
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.
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”
