Got interrupted before I completed this!
On Thu, Apr 21, 2022 at 6:43 PM Nico Kadel-Garcia <[email protected]> wrote:
>
> On Wed, Apr 20, 2022 at 8:55 PM Nico Kadel-Garcia <[email protected]> wrote:
> >
> > On Wed, Apr 20, 2022 at 9:52 AM Matt Martz <[email protected]> wrote:
> > >
> > > 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.
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAOCN9rwgKeDy4hdKptLhkV-LzzWvKUW7MtrhDZ%2BKjO%2BRHfjhTQ%40mail.gmail.com.
