Thanks for all the replies!
Agreed, because if for whatever reason the controller is not able to run the modules, this is exactly where EE’s come in (and you can also run those with ansible-navigator if you don’t have AWX/AAP 
Yes, exactly, and the EL distro’s (RHEL, Rocky, Alma etc.) are impacted most by these due to the /usr/libexec/platform-python begin static
Yes, I’m guessing that once Ansible 2.22 rolls around they drop Pyton 3.9 (given that Python 3.15 is around by then)
Well, not on all distros, I’m not too sure how this works on Debian (it’s been a while), but for EL the modules that interact with for example Yum/DNF have to use /usr/libexec/platform-python, which means for EL8 3.6.8, EL9 3.9.18. And Ansible’s interpreter discovery plugin will always attempt to run modules with that interpreter as well.
And when trying to run a newer version of Ansible on those targets will either result in an error finding a suitable interpreter, or Python errors because the interpreter is not supported.
Indeed, but that’s the point with EL at least, that’s something they explicitly changed when designing RHEL8 (https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8-3 and Chapter 16. Installing and using dynamic programming languages | Configuring basic system settings | Red Hat Enterprise Linux | 8 | Red Hat Documentation)
Agreed and I’m fully in favor of EE’s, because it allows one to have a static, immutable, personalize Ansible executioner. And that on it’s own is brilliant, no more juggling dependencies, installing obscure Python packages from outside of PyPI (looking at you VMware) and hoping nothing breaks this time after upgrading your system. Heck, you can even stick it inside a CI job that runs a test playbook to ensure you can still talk to <insert thing here>!
Well this exactly, I already have to keep everything updated, secured and functioning. And we’re trying real hard to keep the pace (we’re already planning RHEL9 upgrades across the board, because RHEL10 has been released, which mean N-1 is now 9 ), but we can’t keep up if the tools we need to use drop support for the OS-es we need (again, sysadmins don’t always have a choice here).
Well these are the ‘all kinds of hacks that fix compatibility’ that I meant in my post 
And frankly, my work is impossible to do in a reasonable amount of time without tools like Ansible, there’s just too many systems, hardening guidelines to apply, patches to install, you name it.
When doing some more searching I ran across this post from @sivel (Python 3.7+ Impact on EL8 (future for EL9) - #13 by sivel) in which he explained the viewpoint from the Core team’s side of things. Which I can fully understand, but I think we’re going in the wrong direction as of now.
And with regards to what we could possibly do to fix this, I think we have a few options/directions in which we can look:
- Investigate ‘LTS’ releases of Ansible, because most of the major distro’s seem to hover around the same versions, this might just work
- Expand the range of supported Python on the targets only. Controller is fine, because that’s relatively easy to fix with EE’s, vens or some other means (it’s just 1 system/container image after all)
Possible AI lies incoming: I had Chat whip up a table of current supported versions of Debian, Suse, Ubuntu and RHEL and their supposed default version of Python:
| Distro family | Specific distro / version | Default Python version (system) |
|---|---|---|
| EL | RHEL 8 (platform-python) | 3.6 (Red Hat Developer) |
| EL | RHEL 9 (platform-python) | 3.9 (Red Hat Docs) |
| EL | RHEL 10 (platform-python) | 3.12 (Red Hat Docs) |
| Debian | Debian 11 (“Bullseye”) | 3.9 (Debian Wiki) |
| Debian | Debian 12 (“Bookworm”) | 3.11 (Debian Wiki) |
| Debian | Debian 13 (“Trixie”) | 3.13 (Debian Wiki) |
| Ubuntu | Ubuntu 20.04 LTS (“Focal”) | 3.8 (documentation.ubuntu.com) |
| Ubuntu | Ubuntu 22.04 LTS (“Jammy”) | 3.10 (documentation.ubuntu.com) |
| Ubuntu | Ubuntu 24.04 LTS (“Noble”) | 3.12 (documentation.ubuntu.com) |
| Ubuntu | Ubuntu 25.04 (“Plucky”) | 3.13 (documentation.ubuntu.com) |
| SUSE (SLE) | SLES 15 (Base system) | 3.6 (SUSE Documentation) |
| SLES 15 SP4+ (Python 3 module) | SLES 15 SP4 / SP5 | 3.11 (SUSE Documentation) |