# Is there a specific reason ansible-core lost compatibility with python 3.6? **URL:** \ **Category:** Ansible Project\ **Tags:** rhel, fedora, awx\ **Created:** [April 20, 2022, 12:57am UTC](https://forum.ansible.com/t/is-there-a-specific-reason-ansible-core-lost-compatibility-with-python-3-6/36544 "2022-04-20T00:57:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [April 20, 2022, 12:57am UTC](https://forum.ansible.com/t/is-there-a-specific-reason-ansible-core-lost-compatibility-with-python-3-6/36544/1 "2022-04-20T00:57:53Z")
The system python on RHEL 7 and RHEL 8 is now python 3.6, and will be for the remaining lifespan of RHEL 7 for a few years, and of RHEL 8 for at least the next 8 years. It's especially hindered by the general dislike of CentOS 8 and of the multiple yum streams and of "modularity" for RHEL 8, both of which have been burdens to RHEL and CentOS users. So I anticipate RHEL 7 being in use for core servers like ansible servers, or ansible tower or awx, far longer than anticipated. Python 3.8 is available from RedHat for RHEL 8, but not for RHEL 7. The suite of modules published are incomplete: They lack critical python modules like python38-resolvelibs and python38-nose. I'm game to update my RPM building setups to support python3.8 builds for ansible, but seems likea lot of work for an individual contributor when it may be much more easily resolved, and long extend the supportable integration of a commercially supported project by encouraging Red Hat employees to support RedHat's commercial operating systems. I don't currently have an Ansible Tower license in hand, and AWX for RPM based deployment seems to have foundered. Are there no RPM's being used for a contemporary ansible-core, itself, in that commercial offering? If it's entirely reliant on doing "pip install", it will need to be "pip3.8 install" and will only work on RHEL 8 based systems for Red Hat offering for the foreseeable future. And it won't work on RHEL 7, which I anticipate many, many current users staying with rather than facing the unwelcome features of RHEL 8 based systems, such as "modularity", the multiple and sometimes overlapping yum streams, and the "CentOS Stream" fiasco. If someone's already done the work of RPM bundling ansible-core for Ansible Tower, I'd appreciate seeing the .spec files. If not, you're quite welcome to mine, which are based on Fedora work. Nico Kadel-Garcia ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [April 20, 2022, 1:52pm UTC](https://forum.ansible.com/t/is-there-a-specific-reason-ansible-core-lost-compatibility-with-python-3-6/36544/2 "2022-04-20T13:52:01Z")
There are a number of reasons, some of which are related to the fact that Py3.6 had already transitioned to only receiving security fixes by the time we made the decision. We decided to jump to the most recent python version still accepting general bug fixes. There are a number of features such as importlib.resources, dataclasses, contextvars, changes to multiprocessing/threading, PEP563, PEP538, ordered dicts. Some of those align with py3.7, but since RHEL8 didn’t include 3.7 and 3.7 was only receiving security fixes, we jumped to 3.8. Additionally there is a cost associated, both human and monetary, with supporting a larger set of versions. Ultimately we made a decision to only support the 3 most recent upstream Python versions from a controller code perspective. ansible-core 2.14 will transition to supporting Py 3.9-3.11. Our plan for RHEL/CentOS packaging is that ansible-core 2.14 will be packaged on RHEL using Py3.11; You can go back and watch the Ansible contributor summit video for some explanation about these plans. 2.13 will likely transition to being packaged on RHEL using Python 3.9. Note that there is also a difference between controller code and target code. Module code still supports Python 2.7, Python 3.5+, and ansible-core 2.11 added support for “module respawn” to allow a module to respawn itself onto a more appropriate python interpreter that contains the libraries the module needs. We also dropped use of the selinux python bindings in ansible-core and switched to ctypes. As far as RPM packaging, RHEL8.6 and 9.0 (planned release in May iirc) will contain ansible-core 2.12, and all required dependencies. The AAP repo contains ansible-core 2.13. CentOS Stream 8 and 9 both contain ansible-core 2.12 as of now: [https://git.centos.org/rpms/ansible-core/branches](https://git.centos.org/rpms/ansible-core/branches) For EL7, it was explicitly decided to drop support for it as an organization as a controller, so Tower (Automation Controller) and AWX don’t run there either, or at a minimum aren’t tested there. Although I guess an SCL with a newer Python could be used for in house packaging of ansible-core as an RPM for EL7. ---
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [April 21, 2022, 12:55am UTC](https://forum.ansible.com/t/is-there-a-specific-reason-ansible-core-lost-compatibility-with-python-3-6/36544/3 "2022-04-21T00:55:26Z")
> There are a number of reasons, some of which are related to the fact that Py3.6 had already transitioned to only receiving security fixes by the time we made the decision. We decided to jump to the most recent python version still accepting general bug fixes. There are a number of features such as importlib.resources, dataclasses, contextvars, changes to multiprocessing/threading, PEP563, PEP538, ordered dicts. Some of those align with py3.7, but since RHEL8 didn't include 3.7 and 3.7 was only receiving security fixes, we jumped to 3.8. Additionally there is a cost associated, both human and monetary, with supporting a larger set of versions. Ultimately we made a decision to only support the 3 most recent upstream Python versions from a controller code perspective. ansible-core 2.14 will transition to supporting Py 3.9-3.11. Our plan for RHEL/CentOS packaging is that ansible-core 2.14 will be packaged on RHEL using Py3.11; You can go back and watch the Ansible contributor summit video for some explanation about these plans. 2.13 will likely transition to being packaged on RHEL using Python 3.9. Thank you, this is a much more complete answer than I received in the github "issues" for ansible-core. These ansible-core RPMs for CentOS and RHEL 8 were published well after I started my .spec files. I'm glad to see them. On the other hand, I'm alarmed that the SRPM has bundled tarballs of assembled dependencies with no provenance. Listing a version number alongside them is one thing, a URL that points to the source code for the dependencies would be better. Updating the related RPMS to match would be even better, though it could take more work. Almost all other python based RPMs publish a URL for the source code tarball, I'd like to strongly suggest including those for these tarballs. I'll be very surprised if python 3.11 is ready for ansible-core by the time RHEL 8.6 is published. I suppose Dimitri could continue to internally bundle other tarballs if and as needed, but I went through that with Subversion and Samba, and it gets hairy quickly. > Note that there is also a difference between controller code and target code. Module code still supports Python 2.7, Python 3.5+, and ansible-core 2.11 added support for "module respawn" to allow a module to respawn itself onto a more appropriate python interpreter that contains the libraries the module needs. We also dropped use of the selinux python bindings in ansible-core and switched to ctypes. Yes, I've noted this before. It's why the system works well even if the local python is.... a far-advanced python 3, and not available on the target system. I've noticed.. > As far as RPM packaging, RHEL8.6 and 9.0 (planned release in May iirc) will contain ansible-core 2.12, and all required dependencies. The AAP repo contains ansible-core 2.13. CentOS Stream 8 and 9 both contain ansible-core 2.12 as of now: [https://git.centos.org/rpms/ansible-core/branches](https://git.centos.org/rpms/ansible-core/branches) That's good, with the concerns about internally bundled dependencies that I've mentioned. Nico Kadel-Garcia ---
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [April 21, 2022, 10:43pm UTC](https://forum.ansible.com/t/is-there-a-specific-reason-ansible-core-lost-compatibility-with-python-3-6/36544/4 "2022-04-21T22:43:58Z")
> \> > \> There are a number of reasons, some of which are related to the fact that Py3.6 had already transitioned to only receiving security fixes by the time we made the decision. We decided to jump to the most recent python version still accepting general bug fixes. There are a number of features such as importlib.resources, dataclasses, contextvars, changes to multiprocessing/threading, PEP563, PEP538, ordered dicts. Some of those align with py3.7, but since RHEL8 didn't include 3.7 and 3.7 was only receiving security fixes, we jumped to 3.8. Additionally there is a cost associated, both human and monetary, with supporting a larger set of versions. Ultimately we made a decision to only support the 3 most recent upstream Python versions from a controller code perspective. ansible-core 2.14 will transition to supporting Py 3.9-3.11. Our plan for RHEL/CentOS packaging is that ansible-core 2.14 will be packaged on RHEL using Py3.11; You can go back and watch the Ansible contributor summit video for some explanation about these plans. 2.13 will likely transition to being packaged on RHEL using Python 3.9. > These ansible-core RPMs for CentOS and RHEL 8 were published well > after I started my .spec files. I'm glad to see them. On the other Oh, and credit to Kevin Fenzi, I was working mostly on top of his Fedora work. I don't want credit for someone else's work. > hand, I'm alarmed that the SRPM has bundled tarballs of assembled > dependencies with no provenance. Listing a version number alongside > them is one thing, a URL that points to the source code for the > dependencies would be better. Updating the related RPMS to match would > be even better, though it could take more work. Almost all other > python based RPMs publish a URL for the source code tarball, I'd like > to strongly suggest including those for these tarballs. Staring more closely, the tarball for ansible-core itself is labeled as "ansible-[commit].tar.gz", and does not match the 2.12.3 tarbally from pypi. This is non-standard for python modules, and tools, which all come from the pypi.org URL's rather than the git-commit based tarballs. Since the git commit based contents don't quite match the pypi.org published tarball, I'd actually recommend using the pypi.org tarball, since that is what is used for "pip install". The other bundled modules are for:          python38-packaging - this is available by RHEL as a "modular" RPM, run "dnf module enable python38-devel; dnf module enable python38" to get these          python38-pyparsing - this is published by RHEL as a "modular" RPM,          python38-straight-plugin - this is not currentl It also extensively uses a hard-coded "python38" rather than setting "python3\_pkgversion" and "python3\_version" That makes it automatically inconsistent and incompatible with Fedora or EPEL builds. I'd strongly using "pyton%{python3\_pkgversion} instead, and use: this at the start: ---
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [April 21, 2022, 11:02pm UTC](https://forum.ansible.com/t/is-there-a-specific-reason-ansible-core-lost-compatibility-with-python-3-6/36544/5 "2022-04-21T23:02:48Z")
Got interrupted before I completed this! > \> > \> \> > \> \> There are a number of reasons, some of which are related to the fact that Py3.6 had already transitioned to only receiving security fixes by the time we made the decision. We decided to jump to the most recent python version still accepting general bug fixes. There are a number of features such as importlib.resources, dataclasses, contextvars, changes to multiprocessing/threading, PEP563, PEP538, ordered dicts. Some of those align with py3.7, but since RHEL8 didn't include 3.7 and 3.7 was only receiving security fixes, we jumped to 3.8. Additionally there is a cost associated, both human and monetary, with supporting a larger set of versions. Ultimately we made a decision to only support the 3 most recent upstream Python versions from a controller code perspective. ansible-core 2.14 will transition to supporting Py 3.9-3.11. Our plan for RHEL/CentOS packaging is that ansible-core 2.14 will be packaged on RHEL using Py3.11; You can go back and watch the Ansible contributor summit video for some explanation about these plans. 2.13 will likely transition to being packaged on RHEL using Python 3.9. > > \> These ansible-core RPMs for CentOS and RHEL 8 were published well > \> after I started my .spec files. I'm glad to see them. On the other > > Oh, and credit to Kevin Fenzi, I was working mostly on top of his > Fedora work. I don't want credit for someone else's work. > > \> hand, I'm alarmed that the SRPM has bundled tarballs of assembled > \> dependencies with no provenance. Listing a version number alongside > \> them is one thing, a URL that points to the source code for the > \> dependencies would be better. Updating the related RPMS to match would > \> be even better, though it could take more work. Almost all other > \> python based RPMs publish a URL for the source code tarball, I'd like > \> to strongly suggest including those for these tarballs. > > Staring more closely, the tarball for ansible-core itself is labeled > as "ansible-[commit].tar.gz", and does not match the 2.12.3 tarbally > from pypi. This is non-standard for python modules, and tools, which > all come from the pypi.org URL's rather than the git-commit based > tarballs. Since the git commit based contents don't quite match the > pypi.org published tarball, I'd actually recommend using the pypi.org > tarball, since that is what is used for "pip install". > > The other bundled modules are for: > >          python38-packaging - this is available by RHEL as a "modular" > RPM, run "dnf module enable python38-devel; dnf module enable > python38" to get these >          python38-pyparsing - this is published by RHEL as a "modular" RPM, >          python38-straight-plugin - this is not currentl > > It also extensively uses a hard-coded "python38" rather than setting > "python3\_pkgversion" and "python3\_version" That makes it automatically > inconsistent and incompatible with Fedora or EPEL builds. I'd strongly > using "pyton%{python3\_pkgversion} instead, and use: this at the start: # Force python38 for RHEL 8, which has python 3.6 by default %if 0%{?el8} %global python3\_version 3.8 %global python3\_pkgversion 38 # For RHEL 'platform python' insanity: Simply put, no. %global \_\_python3 %{\_bindir}/python%{python3\_version} %endif Also, very strongly consider replacing all the hard-coded "python38" settings with "python%{python3\_pkgversion}" for maximum consistency with Fedora and RHEL 9, or python 3.10 updates. And update the "pathfix3.8.py" command to "python%{python3\_version}.py" python38-straight-plugin is not currently available as an RPM at RHEL, but it's trivial to build, I'd happily send a .spec file for it. I \*intensely\* dislike the modularity deployment approach in use by RHEL 8, I see that Fedora has not a single python module deployed with modularity, and I strongly approve of RHEL abandoning it if possible. It's been very messy to integrate in local 'mock' compilation setups, and it's one of the reasons some devops personnel have been very reluctant to use RHEL 8. Bundling the modules internally to ansible-core got around this problem, but it's an anti-pattern for publishing python based tools.