<div dir="ltr"><div dir="ltr">I am very, very behind on my ALE email, so apologies for replying to this thread a few months late.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2024 at 1:29 PM Steve Litt via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Leam Hall via Ale said on Wed, 19 Jun 2024 12:00:31 -0500<br>
<br>
>On 6/19/24 11:48, Steve Litt via Ale wrote:<br>
>> Leam Hall via Ale said on Wed, 19 Jun 2024 08:01:51 -0500<br>
>>   <br>
>>> Didn't I see a note somewhere about Ansible dropping support for<br>
>>> older versions of Python that are still used on current RHEL<br>
>>> systems? I'm trying to find out more, anyone know?  <br></blockquote><div><br></div><div>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: <a href="https://github.com/ansible/ansible/issues/82068#issuecomment-1781497925">https://github.com/ansible/ansible/issues/82068#issuecomment-1781497925</a></div><div><br></div><div>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.<br></div><div><br></div><div>[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. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If by Developers you mean the developers of the Python language, I<br>
agree. The problem I see is that a lot of those using the Python<br>
language to develop other software are lazy. Too lazy to convert to<br>
3.x, which isn't very difficult if one sticks to Python's standard<br>
library.</blockquote><div><br></div><div>You might think! But Python does not follow <a href="https://semver.org/">https://semver.org/</a> 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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>and I understand why Linux versions<br>
>use open source components. The issue may be that development is<br>
>accelerating faster than enterprise Linux versions can transition.<br>
<br>
10 years? Maybe the enterprise Linux versions are promising too long a<br>
lifetime.<br></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Maybe it's time for a more stable language?<br>
<br>
Can't get any more stable than C, which can still compile and run 80's<br>
code.</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When it comes to language stability over time, there's a happy medium.<br>
You don't want it so stable that it never acquires new features, or if<br>
it does, they're glued on as an afterthought (e.g. Perl objects). And<br>
you don't want it so quickly changing that you begin new construction<br>
in different versions (e.g. Lua). I think Python and Ruby are in the<br>
Goldilocks Zone.<br clear="all"></blockquote><div><br></div><div>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".<br></div></div><div><br></div><div>[2]: And I mean Ruby, not Ruby on Rails.</div><div>[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.<br></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Dylan Northrup<br>"Now that is a powerful cat"<br></div>  - Aesop Rock<br></div></div></div>