5 ms·

No, the original was finished. Feature complete, bug free software doesn’t need to have patches released every week. That is the ultimate goal of a small utili

No, the original was finished. Feature complete, bug free software doesn’t need to have patches released every week. That is the ultimate goal of a small utility like this. It’s a shame that so many developers mistake this state for “unmaintained”or “abandoned”.

nemothekid 7y ago
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.
- mehrdadn 7y ago
  > 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], ...
  - Conan_Kudo 7y ago
    Mercurial 5.0 is Python 3 compatible. The Python code in Git is Python 3 compatible. I don't know about TeXLive or Graphviz, though...
    - mehrdadn 7y ago
      Confused, so why is Python 2 a requirement? Name : mercurial Version : 5.0-1 Description : A scalable distributed SCM tool Depends On : python2 Optional Deps : tk: for the hgk GUI [installed] Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 25.95 MiB
      - Macha 7y ago
        Possible options: 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.
        Macha 7y ago
        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: https://www.mercurial-scm.org/wiki/Release5.0 https://www.mercurial-scm.org/wiki/Release5.0
        mehrdadn 7y ago
        Weird that it says Windows is the issue but I'm seeing this on Linux.
  - bonzini 7y ago
    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.
  - Macha 7y ago
    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.
    - mehrdadn 7y ago
      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.
      - user5994461 7y ago
        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.
- zonidjan 7y ago
  Python 2 is EOL? Interesting. https://pythonclock.org/ https://pythonclock.org/
  - nightfly 7y ago
    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.

nemothekid 7y ago

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.

mehrdadn 7y ago
> 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], ...
- Conan_Kudo 7y ago
  Mercurial 5.0 is Python 3 compatible. The Python code in Git is Python 3 compatible. I don't know about TeXLive or Graphviz, though...
  - mehrdadn 7y ago
    Confused, so why is Python 2 a requirement? Name : mercurial Version : 5.0-1 Description : A scalable distributed SCM tool Depends On : python2 Optional Deps : tk: for the hgk GUI [installed] Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 25.95 MiB
    - Macha 7y ago
      Possible options: 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.
      - Macha 7y ago
        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: https://www.mercurial-scm.org/wiki/Release5.0 https://www.mercurial-scm.org/wiki/Release5.0
        mehrdadn 7y ago
        Weird that it says Windows is the issue but I'm seeing this on Linux.
- bonzini 7y ago
  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.
- Macha 7y ago
  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.
  - mehrdadn 7y ago
    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.
    - user5994461 7y ago
      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.
zonidjan 7y ago
Python 2 is EOL? Interesting. https://pythonclock.org/ https://pythonclock.org/
- nightfly 7y ago
  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.