The software isn't finished if the runtime it runs on has been EOL'd.
dstat, up until earlier this year (a couple weeks before that announcement), did not support Python 3 - and the author may have just merged RedHat's changes anyways. RedHat's "fork" supported Python3 for months at that point.
Yes, it was a useful tool, and what RedHat did was shitty but I can understand the motivation for not wanting to keep a Python2 install around just for one tool.
> I can understand the motivation for not wanting to keep a Python2 install around just for one tool.
I don't use a Red Hat distro but would this really only be one tool? On Arch I see the following packages depend on python2: mercurial [required], git [optional], texlive-core [optional], graphviz [optional], ...
RHEL8 doesn't include a Python 2 runtime that is supported for the whole life of the distro. There are a couple exceptions where Python 2 is used at build time, but that's it.
At the point when people started to work on pcp-dstat, it was clear that if you wanted X in the base distribution it had to be Python 3 compatible.
Arch doesn't promise support. Red Hat does. If software in Arch is unsupported in the near future but currently works, that's less of a problem than software in RHEL becoming definitely unsupported during the release lifetime.
Yes but that doesn't really answer my question. My question was if these programs use Python 3 then why would Arch -- which generally has the latest versions of programs unmodified -- have them depending on Python 2. You just explained why depending on Python 2 is not a problem... which is answering a different question.
Anything python2 is a problem, because Python 2 is officially end of life in January 2020. It is being dropped from all major linux distributions, along any software that depends on it.
RedHat 8 that just got released this month doesn't have it. Not sure when is the next release/update cycle for Arch, that will drop it. Keeping in mind that Arch probably doesn't care about doing things last minute or even after the due date.
1. Some of mercurial's bundled plugins are not Py3 compatible (I recall reading a discussion as an outsider a while back that some plugins are planned to be ported to Rust, not Python 3, but that may have changed)
2. Nobody involved in packaging it for Arch has had time to verify mercurial 5 on python 3.
So looking into this a bit more (and my edit window has expired), it's because the mercurial team themselves suggest not to package mercurial 5.0 for python 3 yet:
I don't understand what you're trying to do with your comment. It might not be EOL quite yet, but 7 months into the future isn't very long.
Especially since RHEL 8 is gonna stick around for the next decade, it's a good idea to move as much stuff as possible to a newer platform that will continue to have security updates at least provided and written by the authors of the platform.
dstat, up until earlier this year (a couple weeks before that announcement), did not support Python 3 - and the author may have just merged RedHat's changes anyways. RedHat's "fork" supported Python3 for months at that point.
Yes, it was a useful tool, and what RedHat did was shitty but I can understand the motivation for not wanting to keep a Python2 install around just for one tool.