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.