Python version(s) for custom plugins

On the flip side — that is, from the custom content (plugin) creators’ perspective — and spurred by this discussion: Maintain Ansible 9 for longer than 6 months, I have a question. Maybe this is more a Python thing than a strictly Ansible thing, but since all my Python code is somehow Ansible related the two are seriously intertwingled in my head.

Is there a process, tool, utility, etc. that a plugin creator can use to determine the minimum and maximum versions of Python required to safely run a particular .py file? I’m not seriously into the weeds on the differences between various Python versions. My pouring over Python change logs and release notes wouldn’t significantly increase my chances of catching a version related issue in one of my plugins anyway. If there were a tool I could point at a plugin and it would spit out an acceptable version spec, that would go a long way toward solving a problem I’ve simply ignored up until now. A huge bonus would be if such a tool could recommend specific changes, or point to docs about such, to help future-proof such code.

I’m not trying to be lazy — it comes naturally! — but life is short, and I’d rather not dedicate more than necessary to a task that a tool could do better and quicker than I could anyway.

1 Like

There isn’t a proper way to do that. You can mention in the plugin’s DOCUMENTATION’s requirements fields which version of Python you support, but that field is not machine-readable, so its more informational for users than anything else.

If it’s a collection, you can indirectly do this by restricting the ansible-core version in meta/runtime.yml, which combined with Releases and maintenance — Ansible Core Documentation restricts the set of Python versions. (It’s not a very precise way to restrict it though…)

The only place where you can specify supported Python versions in a machine-readable way is the ansible-test configuration for a collection (template: http://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/config/config.yml), which needs to be placed in tests/config.yml and restricts the Python version suppoted by modules to a specific set (or simply to controller). This only applies to modules, though, you cannot restrict the Python versions for plugins, they are always expected to support all Python versions the controller can run with.

The best way is probably to have your plugin covered by unit tests and check for Python deprecation warnings in the ansible-test units output.

Regarding the main part of your question, I unfortunately don’t have an idea. I hope someone else has :slight_smile:

2 Likes

From an Ansible perspective, that’s a reasonable way to go. Thanks.

Alas, my “development process” is generously described as in the “hunter-gatherer” stage: snippets of indeterminate vintage code scoured from the internet, blended and tweaked to a purpose. I’d like to hope these tiny bundles of functionality age more like wine than milk for the sake of my teammates who will inherit them. I spent the first years of my career building stuff I thought would last forever. The next twenty were filled with re-implementing and decommissioning all of it. With 40 years in now, I’m not sure how I feel about leaving this stuff for others to ponder.

Something that can spit out “Python deprecation warnings” — That’s an attractive prospect indeed.