# Ansible supported Python version on \_target\_ **URL:** \ **Category:** Project Discussions\ **Tags:** ansible, ansible-core, linux\ **Created:** [November 19, 2025, 3:31pm UTC](https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863 "2025-11-19T15:31:23Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![Thulium-Drake](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/thulium-drake/32/833_2.png) [@Thulium-Drake](https://forum.ansible.com/u/Thulium-Drake)\ **Post date:** [November 20, 2025, 6:18am UTC](https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863/6 "2025-11-20T06:18:41Z")
Thanks for all the replies! > [@felixfontein](#): > > I think dropping support for older Python versions _on the controller_ is perfectly fine. 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 🙂 > [@felixfontein](#): > > But that still doesn’t solve the ansible-core problem, where a new enough ansible-core version effectively prevents execution of modules and module utils 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 > [@felixfontein](#): > > I’m assuming you mean a new ansible-core 2.x.0 release. (And not a new Python 3.y.0 release.) 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) > [@mariolenz](#): > > Can’t you just install a newer version the target and it just works? Or wouldn’t this work because the default python version (3.6) is used? 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. > [@felixfontein](#): > > Especially 2. is the main reason why the situation sucks so much… If the only disadvantage would be that you need to install a newer Python first (somehow), it would be a lot easier. 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](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](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/installing-and-using-dynamic-programming-languages_configuring-basic-system-settings)) > [@rfc2549](#): > > Execution environments (as built/meant for awx/aap) lets you pick your version of python, ansible-core, ansible, dependencies and other things but at the end of the day it’s not fundamentally different than using a regular container image or a virtualenv of your preferred python interpreter.. 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 ``! > [@rfc2549](#): > > It’s ok to expect users to update to modern distributions but reality is we are busy and we do not always have the luxury of keeping thousands of machines upgraded easily 😛 > > I just mean to point out that dropping python versions for distros that are still supported can be a big papercut. 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). > [@rfc2549](#): > > Yes, we can probably jump through hoops to get the right version of a python interpreter installed somehow. 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](https://forum.ansible.com/t/python-3-7-impact-on-el8-future-for-el9/6229/13)) 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](https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8-3?utm_source=chatgpt.com "Python in RHEL 8 | Red Hat Developer")) | | EL | RHEL 9 (platform-python) | **3.9** ([Red Hat Docs](https://docs.redhat.com/es/documentation/red_hat_enterprise_linux/9/html/installing_and_using_dynamic_programming_languages/assembly_introduction-to-python_installing-and-using-dynamic-programming-languages?utm_source=chatgpt.com "Chapter 1. Introduction to Python | Installing and using dynamic programming languages | Red Hat Enterprise Linux | 9 | Red Hat Documentation")) | | EL | RHEL 10 (platform-python) | **3.12** ([Red Hat Docs](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/pdf/installing_and_using_dynamic_programming_languages/Red_Hat_Enterprise_Linux-10-Installing_and_using_dynamic_programming_languages-en-US.pdf?utm_source=chatgpt.com "Red Hat Enterprise Linux 10")) | | Debian | Debian 11 (“Bullseye”) | **3.9** ([Debian Wiki](https://wiki.debian.org/Python?utm_source=chatgpt.com "Python - Debian Wiki")) | | Debian | Debian 12 (“Bookworm”) | **3.11** ([Debian Wiki](https://wiki.debian.org/Python?utm_source=chatgpt.com "Python - Debian Wiki")) | | Debian | Debian 13 (“Trixie”) | **3.13** ([Debian Wiki](https://wiki.debian.org/Python?utm_source=chatgpt.com "Python - Debian Wiki")) | | Ubuntu | Ubuntu 20.04 LTS (“Focal”) | **3.8** ([documentation.ubuntu.com](https://documentation.ubuntu.com/ubuntu-for-developers/reference/availability/python/?utm_source=chatgpt.com "Available Python versions - Ubuntu for Developers")) | | Ubuntu | Ubuntu 22.04 LTS (“Jammy”) | **3.10** ([documentation.ubuntu.com](https://documentation.ubuntu.com/ubuntu-for-developers/reference/availability/python/?utm_source=chatgpt.com "Available Python versions - Ubuntu for Developers")) | | Ubuntu | Ubuntu 24.04 LTS (“Noble”) | **3.12** ([documentation.ubuntu.com](https://documentation.ubuntu.com/ubuntu-for-developers/reference/availability/python/?utm_source=chatgpt.com "Available Python versions - Ubuntu for Developers")) | | Ubuntu | Ubuntu 25.04 (“Plucky”) | **3.13** ([documentation.ubuntu.com](https://documentation.ubuntu.com/ubuntu-for-developers/reference/availability/python/?utm_source=chatgpt.com "Available Python versions - Ubuntu for Developers")) | | SUSE (SLE) | SLES 15 (Base system) | **3.6** ([SUSE Documentation](https://documentation.suse.com/releasenotes/legacy/sles/15-SP5/index.html?utm_source=chatgpt.com "Release Notes | SUSE Linux Enterprise Server 15 SP5")) | | SLES 15 SP4+ (Python 3 module) | SLES 15 SP4 / SP5 | **3.11** ([SUSE Documentation](https://documentation.suse.com/releasenotes/legacy/sles/15-SP5/index.html?utm_source=chatgpt.com "Release Notes | SUSE Linux Enterprise Server 15 SP5")) | --- _[View the full topic](https://forum.ansible.com/t/ansible-supported-python-version-on-target/44863)._