How to not conflict on external collection versions?

Get Help
,
1

You’re a collection and playbook author for your organization. You have multiple collections that depend on an external community collection. Let’s say amazon.aws. In your collections, do you have your collections depend on amazon.aws without a version constraint and let the playbook depending on your collections also depend on amazon.aws with a concrete version? Do you depend on amazon.aws and depend on, say, ‘>=8’?

I’m trying to get some ideas on how other collection authors try to steer away from having two or more of their collections colliding on versions of dependencies.

2

I would recommend against putting the dependencies into your playbooks, unless your playbooks call modules in the collection. Instead, attach them to the collections in the galaxy.yaml file. See
community.aws/galaxy.yml at main · ansible-collections/community.aws · GitHub for an example of depending on amazon.aws in a collection

Yes, I’d generally use “>=”, but you should also beware that collections can have breaking changes in major versions. For example in amazon.aws 8.0.0 some modules changed their return information, so you may have code which depends on “<8”…

3

Thanks for the response. Yeah I didn’t necessarily want to put the concrete version of the external collection in the playbook that doesn’t directly depend on it. I was also leaning towards ‘>=’ and yes we’ve gotten bit by breaking changes as well.

One thing I’ve not seen in Ansible docs is the ability to specify versioning using tilde (~) or caret (^) the way you can in, say, npm. It would be great to specify ‘~8’ for amazon.aws in order to mean ‘>=8,<9’. I don’t even think you can specify ‘>=8,<9’ can you?

4

https://docs.ansible.com/ansible/latest/dev_guide/collections_galaxy_meta.html#examples

The example seems to say you can…

dependencies:
    "other_namespace.collection1": ">=1.0.0"
    "other_namespace.collection2": ">=2.0.0,<3.0.0"
    "anderson55.my_collection": "*"    # note: "*" selects the highest version available
5

We generally try not to break too much between versions (biggest breaking change is the minimum botocore requirement). Personally I’d only recommend adding the “<9” if you specifically know 9 breaks something, and that would generally be something you could check on a per-custom-collection basis (assuming you’re not using every module in amazon.aws :slight_smile: ).

6

Excellent news.

Typically we try to use just the major version of any external library even if the next major version isn’t out yet so that when it does get released, we don’t break everything internally on day one. So even if amazon.aws doesn’t yet have 9.x , it’s a safeguard for us to constrain the current requirement to ‘<9’. After all, in semantic versioning land, major version releases do denote breaking changes.

7

Having upper bounds is usually a good idea, but you should have some mechanism in place which checks for when new major releases are out so you from time to time can update these upper bounds (after some testing and potential adjustments, if necessary), otherwise after some years you end up using very old versions of the collections with a lot of bugs that have been fixed years ago which eventually are no longer compatible with the latest SDKs / libraries :slight_smile:

1 Like