[ale] Ansible and Python comment?

[Dylan Northrup]

I am very, very behind on my ALE email, so apologies for replying to this
thread a few months late.

On Wed, Jun 19, 2024 at 1:29 PM Steve Litt via Ale <ale at ale.org> wrote:

> Leam Hall via Ale said on Wed, 19 Jun 2024 12:00:31 -0500
>
> >On 6/19/24 11:48, Steve Litt via Ale wrote:
> >> Leam Hall via Ale said on Wed, 19 Jun 2024 08:01:51 -0500
> >>
> >>> Didn't I see a note somewhere about Ansible dropping support for
> >>> older versions of Python that are still used on current RHEL
> >>> systems? I'm trying to find out more, anyone know?
>

The issue I have seen is versions of ansible-core after 2.16 will fail[1]
when running certain tasks on RHEL systems that shipped with python3.6.
There is an ansible issue for this, but to save reading the whole issue,
here's the link to Matt Clay's response:
https://github.com/ansible/ansible/issues/82068#issuecomment-1781497925

If you need to use ansible to manage RHEL8 systems, the workaround is a)
upgrade to RHEL9 or b) do not ansible versions after 2.16.

[1]: Ansible 2.17 will use the "system" python when running on remote
boxes. One of the ansible helper modules, `basic.py`, contains `from
__future__ import annotations`. That works on python 3.6, but doesn't on
3.7. If you're able to get by this check (by pointing ansible at a newer
python interpreter), you will still run into issues with certain tasks
(installing packages via `yum`/`dnf` being the ones that tripped me up)
because 1) the modules used by those tasks also contain `from __future__
import annotations` and 2) you cannot install updated versions via pip
because the modules themselves don't allow it without additional
modification.

If by Developers you mean the developers of the Python language, I
> agree. The problem I see is that a lot of those using the Python
> language to develop other software are lazy. Too lazy to convert to
> 3.x, which isn't very difficult if one sticks to Python's standard
> library.


You might think! But Python does not follow https://semver.org/ and makes
breaking changes in minor versions of its core libraries (like, y'know,
having `from __future__import annotations` work on 3.6 but not work on
3.7). One more reason I'm not a Python fan.


> >and I understand why Linux versions
> >use open source components. The issue may be that development is
> >accelerating faster than enterprise Linux versions can transition.
>
> 10 years? Maybe the enterprise Linux versions are promising too long a
> lifetime.
>

Some shops work on long refresh cycles and/or don't properly maintain their
systems post-launch. To make changes you often need agreement from many
stakeholders. It is far more likely someone will say "no" than everyone
will say "yes". For example... When I was working at a "large broadcaster"
in Atlanta, there was a system in a production pipeline running Netscape
Application Server on whatever version of Solaris shipped on Sun boxes in
the ~2000 time frame. This was brought to my attention during the "we must
cloudify everything" push of Q4 2019/Q1 2020. No, the organization that
used the production pipeline was not interested (and likely did not have
the expertise) in testing whatever replacement might be put in place by
whatever other team would develop it. No time and we gots ta work on new
features, dontchaknow.


> >Maybe it's time for a more stable language?
>
> Can't get any more stable than C, which can still compile and run 80's
> code.


It's not whether the code compiles, it's whether it runs. Are you linking
against libc? Oh, that doesn't work in this apline container. Compiled for
x86? Oh, we're using ARM hosts.


> When it comes to language stability over time, there's a happy medium.
> You don't want it so stable that it never acquires new features, or if
> it does, they're glued on as an afterthought (e.g. Perl objects). And
> you don't want it so quickly changing that you begin new construction
> in different versions (e.g. Lua). I think Python and Ruby are in the
> Goldilocks Zone.
>

Ruby is my preference for an interpreted language[2]. Go is my preference
for a compiled language[3]. Bash is my preference for a "must run on *nix
systems where you can assume only a base install".

[2]: And I mean Ruby, not Ruby on Rails.
[3]: It's very easy to cross-compile to target other hardware and OS
platforms and, presuming you're not doing system/hardware fiddling,
requires no code changes.

-- 
Dylan Northrup
"Now that is a powerful cat"
  - Aesop Rock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20240912/c7803526/attachment.htm>