8 ms·

What? This isn't about "languages". It's about software! Algol 68 and Fortran 77 may have stale (but maintained) compilers or interpreters in the package repos

by DCKing 7y ago

What? This isn't about "languages". It's about software! Algol 68 and Fortran 77 may have stale (but maintained) compilers or interpreters in the package repository. Starting very soon - Python 2 will have an entire set of unmaintained runtime and libraries in the package repository. You know - actual, offically, unmaintained software! Unmaintained software that other packages, including Calibre in this example, further build on. Of course they're throwing this out. If you're concerned about language support there are multiple solutions like: * Port your stuff to Python 3 and enjoy first class support * Running Debian Buster * Running CentOS 8, which will probably profit from RHEL 8's Python 2 support-with-an-asterisk until 2029 [1]. * Installing it manually on your system * Installing it manually in a container This is how it feels to run legacy software - it's bloody inconvenient. But that's not a problem Debian needs to solve for anyone. [1]: https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/ https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

CJefferson 7y ago
Python 2 is only unmaintained because the Python foundation is refusing to let anyone "officially" take over support. There are thousands of programs in Debian with less core developers than Python 2 working just fine.
- maxerickson 7y ago
  It's understandable that the PSF wouldn't endorse a maintainer. They can't stop someone from releasing something that runs just like Python 2 and has a different name.
  - CJefferson 7y ago
    That's true, but it might make packaging tricky -- lots of the old Python 2 software people want to run will have '#!/usr/bin/env python' hard-wired in, and having to fix those would be annoying.
    - PeterisP 7y ago
      You'd have to fix those lines anyway, since /usr/bin/env python will be pointing to python3 executable in the new releases, not python2.
      - oconnor663 7y ago
        It's been that way on Arch Linux for years, but I wouldn't expect most other platforms to make that switch for some time, if ever.
        saghm 7y ago
        Isn't this article an indication that Debian intends to? I'd also guess there's a pretty good chance that distros based on Debian (e.g. Ubuntu) will follow that switch
        mjw1007 7y ago
        As far as I know Debian intends to have no plain `python` on the default PATH once the python2 packages are removed, so that it will be up to the system administrator to decide where that will point. See eg https://lists.debian.org/debian-python/2018/05/msg00063.html https://lists.debian.org/debian-python/2018/05/msg00063.html from the Debian Python maintainer. (That's a year and a half old, but I haven't seen a message go past suggesting they've changed their minds.)
        saghm 7y ago
        Interesting! That seems like a reasonable solution to me, but I also have no dog in that race since I don't use Debian or write much Python code.
        PeterisP 7y ago
        Starting next year, I'd expect most other platforms will not include python2 in the default distribution, so the default "python" can either point to python3 or nothing at all.
  - sitkack 7y ago
    In the case, the name is utility and not an artifact. I would argue that having the same name is necessary to even having a workalike, at least for a system command and a symlink. As long time Python user, my view of the PSF is that they could mature a little bit. Their ambivalent hostility towards PyPy and Jython, the lack of portable standard library, and now with how they are continuing to mismanage the 2to3 transition. None of this is how adults should behave.
- viraptor 7y ago
  You can fork it, rename it, and make it provide python2 binary via both Debian alternatives and package-provides, then ask for inclusion in upstream. There's nothing that stops you and it's done for other languages as well. For example in C you have GCC and llvm providing cc.
- zanny 7y ago
  Red Hat has already announced their intent to maintain Python 2 in RHEL for ~4 years.
ahbyb 7y ago
Debian could just take RHEL's fork of Python 2. Why don't they do that?
- DCKing 7y ago
  Because: * Everybody knows they should have moved to Python 3 for over three major versions of Debian stable. * Debian is not committed to keep legacy software running in perpituity in new versions. * For Debian Buster they have already committed to supporting Python 2 until at least 2022 - and probably 2024 for LTS. They're already putting in the commitment! * The next version of Debian stable will probably be released mid 2021 - long after Python 2's EOL of Jan 1. * RHEL's Python 2 support amounts to life support at best. * Keeping around legacy software takes precious volunteer time - which is all Debian has.
  - linuxftw 7y ago
    > they have already committed to supporting Python 2 until at least 2022 - and probably 2024 for LTS. They're already putting in the commitment! This is the entire point of a stable distro. To pick some software, stabilize it a specific api, and keep it supported. Upstream need-not support that specific version of a release, for reference, see the kernel.
    - SiempreViernes 7y ago
      Make your own Debian fork and stop pestering the rest of us about how volunteers should support software they aren't interested in.
      - linuxftw 7y ago
        Huh? I'm just saying it's not unreasonable to support software downstream that upstream doesn't. That's the entire point. I don't care what Debian does at this point, too old for practical use. > should support software they aren't interested in. You mean like pestering all the other package maintainers to support python3 when they're not interested in doing that? That goes both ways. Nobody wanted python3, expect PSF. This is the continued backlash.
greglindahl 7y ago
Fortran 77 doesn't have a stale compiler; modern Fortran compilers support Fortran back to the beginning of time. Almost all of the weirdnesses are limited to the front-end, so it's not that difficult to support.

by DCKing 7y ago

CJefferson 7y ago

Python 2 is only unmaintained because the Python foundation is refusing to let anyone "officially" take over support. There are thousands of programs in Debian with less core developers than Python 2 working just fine.

maxerickson 7y ago
It's understandable that the PSF wouldn't endorse a maintainer. They can't stop someone from releasing something that runs just like Python 2 and has a different name.
- CJefferson 7y ago
  That's true, but it might make packaging tricky -- lots of the old Python 2 software people want to run will have '#!/usr/bin/env python' hard-wired in, and having to fix those would be annoying.
  - PeterisP 7y ago
    You'd have to fix those lines anyway, since /usr/bin/env python will be pointing to python3 executable in the new releases, not python2.
    - oconnor663 7y ago
      It's been that way on Arch Linux for years, but I wouldn't expect most other platforms to make that switch for some time, if ever.
      - saghm 7y ago
        Isn't this article an indication that Debian intends to? I'd also guess there's a pretty good chance that distros based on Debian (e.g. Ubuntu) will follow that switch
        mjw1007 7y ago
        As far as I know Debian intends to have no plain `python` on the default PATH once the python2 packages are removed, so that it will be up to the system administrator to decide where that will point. See eg https://lists.debian.org/debian-python/2018/05/msg00063.html https://lists.debian.org/debian-python/2018/05/msg00063.html from the Debian Python maintainer. (That's a year and a half old, but I haven't seen a message go past suggesting they've changed their minds.)
        saghm 7y ago
        Interesting! That seems like a reasonable solution to me, but I also have no dog in that race since I don't use Debian or write much Python code.
      - PeterisP 7y ago
        Starting next year, I'd expect most other platforms will not include python2 in the default distribution, so the default "python" can either point to python3 or nothing at all.
- sitkack 7y ago
  In the case, the name is utility and not an artifact. I would argue that having the same name is necessary to even having a workalike, at least for a system command and a symlink. As long time Python user, my view of the PSF is that they could mature a little bit. Their ambivalent hostility towards PyPy and Jython, the lack of portable standard library, and now with how they are continuing to mismanage the 2to3 transition. None of this is how adults should behave.
viraptor 7y ago
You can fork it, rename it, and make it provide python2 binary via both Debian alternatives and package-provides, then ask for inclusion in upstream. There's nothing that stops you and it's done for other languages as well. For example in C you have GCC and llvm providing cc.
zanny 7y ago
Red Hat has already announced their intent to maintain Python 2 in RHEL for ~4 years.

ahbyb 7y ago

Debian could just take RHEL's fork of Python 2. Why don't they do that?

DCKing 7y ago
Because: * Everybody knows they should have moved to Python 3 for over three major versions of Debian stable. * Debian is not committed to keep legacy software running in perpituity in new versions. * For Debian Buster they have already committed to supporting Python 2 until at least 2022 - and probably 2024 for LTS. They're already putting in the commitment! * The next version of Debian stable will probably be released mid 2021 - long after Python 2's EOL of Jan 1. * RHEL's Python 2 support amounts to life support at best. * Keeping around legacy software takes precious volunteer time - which is all Debian has.
- linuxftw 7y ago
  > they have already committed to supporting Python 2 until at least 2022 - and probably 2024 for LTS. They're already putting in the commitment! This is the entire point of a stable distro. To pick some software, stabilize it a specific api, and keep it supported. Upstream need-not support that specific version of a release, for reference, see the kernel.
  - SiempreViernes 7y ago
    Make your own Debian fork and stop pestering the rest of us about how volunteers should support software they aren't interested in.
    - linuxftw 7y ago
      Huh? I'm just saying it's not unreasonable to support software downstream that upstream doesn't. That's the entire point. I don't care what Debian does at this point, too old for practical use. > should support software they aren't interested in. You mean like pestering all the other package maintainers to support python3 when they're not interested in doing that? That goes both ways. Nobody wanted python3, expect PSF. This is the continued backlash.

greglindahl 7y ago

Fortran 77 doesn't have a stale compiler; modern Fortran compilers support Fortran back to the beginning of time. Almost all of the weirdnesses are limited to the front-end, so it's not that difficult to support.