8 ms·

Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support. I doubt anyone is checking

Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support. I doubt anyone is checking for potential security problems in the Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that. It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran. In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.

cptskippy 7y ago
The implementations of Algol and Fortran for Debian are maintained.
Certhas 7y ago
Nothing about this is aggressive. And having maintained compilers for ancient languages is really really different from having an unmaintained, obsolete runtime/interpreter/ecosystem. And nothing is stopping you from installing Python 2. All scientists I know rely on anaconda to manage their Python environment, and couldn't care less what the system python does. I really _don't_ want to rely on system python for reproducing my old results.
- semi-extrinsic 7y ago
  On the flipside: how useful is your code really if it's not reproducible with a modern Python version? From 3.3 to 3.8, there should be perfect backwards compatibility? For packages, I can understand it, sure. So include a requirements.txt, and just spin up a 3.8 virtualenv to reproduce, no?
  - samus 7y ago
    Backwards compatibility is there, but minor changes and patches might mean different things for certain users. One can never be sure without sifting throug changelogs and maintaining test suites. And that is for stuff you know you are looking for.
  - hermitdev 7y ago
    You mean like the recent issue that affected over a hundred papers because they assumed Python's glob module returned files in a sorted fashion and they depended upon the order the files were processed?
    - semi-extrinsic 7y ago
      Well, that's kinda what I was saying. How useful is your code really, if it depends on the order in a list of files in a fragile way that's hard to fix if the order changes?
      - Dylan16807 7y ago
        Probably very useful. Any big codebase is going to have lots of implicit dependencies by accident. It requires active development to stay compatible, and it's okay to not be perfect.
dbdjfjrjvebd 7y ago
Fortran has maintained nearly full backwards compatibility.
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
djsumdog 7y ago
Recently I had to get some old Rails 1.8 apps running so I could get some screenshots for an upcoming project. Docker containers are great for this. It took a while to get everything working, but now I can export those container images and always have a version of these old projects I can run on a container runtime. I'll never use them for production of course, but they're good historically. As others have stated, those are old implementations, but I'm sure Debain will still accept security patches for them. Python2 is about to lose major support. You cannot just let rotting dependencies stick around in your tree. You're not going to have a good time. If people really want that stuff, they can pack it into a Docker container, or Snap/Flatpack/whatever garbage for old GUI applications.
- whalesalad 7y ago
  Hats off to you for booting an old 1.8 app! That is prehistoric!
- londons_explore 7y ago
  I guess in 10 years time, when dockerhub goes away, and most of the packaging scripts have broken online dependencies, a bunch of those docker images are going to be really hard to rebuild...
weichi 7y ago
"In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that." But if this is important to you then depending on the OS to provide your python seems like a bad idea, independent of the python2/python3 issues. Wouldn't it be much better to use something like conda / the anaconda distribution, so that you can specify precise versions of each library for your environment? Having said that, I don't know how anaconda is going to handle the EOL of python2. So I guess the question is: if someone wants to be able to reliably reproduce a python2 environment with specific set of libraries, what is best way to do that?
- darkarmani 7y ago
  > Having said that, I don't know how anaconda is going to handle the EOL of python2. So I guess the question is: if someone wants to be able to reliably reproduce a python2 environment with specific set of libraries, what is best way to do that? What's to handle? Old versions of python2 packages are still in the online repos. The EOL means that there won't be any new releases to python. All of the old releases will still work though.
- nitroll 7y ago
  Distributing a container, virtual machine or something similar.
- maweki 7y ago
  Yeah, our bioinformatics department is already using anaconda extensively.
yrro 7y ago
Developers and scientists, in my experience, prefer to get the latest Python wheels from the Internet rather than reply on distributions to curate their packages. The consumers of distribution-provided packages is... other distribution-provided packages.
minusf 7y ago
python is 29 years old :}

cptskippy 7y ago

The implementations of Algol and Fortran for Debian are maintained.

Certhas 7y ago

Nothing about this is aggressive. And having maintained compilers for ancient languages is really really different from having an unmaintained, obsolete runtime/interpreter/ecosystem. And nothing is stopping you from installing Python 2. All scientists I know rely on anaconda to manage their Python environment, and couldn't care less what the system python does. I really _don't_ want to rely on system python for reproducing my old results.

semi-extrinsic 7y ago
On the flipside: how useful is your code really if it's not reproducible with a modern Python version? From 3.3 to 3.8, there should be perfect backwards compatibility? For packages, I can understand it, sure. So include a requirements.txt, and just spin up a 3.8 virtualenv to reproduce, no?
- samus 7y ago
  Backwards compatibility is there, but minor changes and patches might mean different things for certain users. One can never be sure without sifting throug changelogs and maintaining test suites. And that is for stuff you know you are looking for.
- hermitdev 7y ago
  You mean like the recent issue that affected over a hundred papers because they assumed Python's glob module returned files in a sorted fashion and they depended upon the order the files were processed?
  - semi-extrinsic 7y ago
    Well, that's kinda what I was saying. How useful is your code really, if it depends on the order in a list of files in a fragile way that's hard to fix if the order changes?
    - Dylan16807 7y ago
      Probably very useful. Any big codebase is going to have lots of implicit dependencies by accident. It requires active development to stay compatible, and it's okay to not be perfect.

dbdjfjrjvebd 7y ago

Fortran has maintained nearly full backwards compatibility.

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

djsumdog 7y ago

Recently I had to get some old Rails 1.8 apps running so I could get some screenshots for an upcoming project. Docker containers are great for this. It took a while to get everything working, but now I can export those container images and always have a version of these old projects I can run on a container runtime. I'll never use them for production of course, but they're good historically. As others have stated, those are old implementations, but I'm sure Debain will still accept security patches for them. Python2 is about to lose major support. You cannot just let rotting dependencies stick around in your tree. You're not going to have a good time. If people really want that stuff, they can pack it into a Docker container, or Snap/Flatpack/whatever garbage for old GUI applications.

whalesalad 7y ago
Hats off to you for booting an old 1.8 app! That is prehistoric!
londons_explore 7y ago
I guess in 10 years time, when dockerhub goes away, and most of the packaging scripts have broken online dependencies, a bunch of those docker images are going to be really hard to rebuild...

weichi 7y ago

"In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that." But if this is important to you then depending on the OS to provide your python seems like a bad idea, independent of the python2/python3 issues. Wouldn't it be much better to use something like conda / the anaconda distribution, so that you can specify precise versions of each library for your environment? Having said that, I don't know how anaconda is going to handle the EOL of python2. So I guess the question is: if someone wants to be able to reliably reproduce a python2 environment with specific set of libraries, what is best way to do that?

darkarmani 7y ago
> Having said that, I don't know how anaconda is going to handle the EOL of python2. So I guess the question is: if someone wants to be able to reliably reproduce a python2 environment with specific set of libraries, what is best way to do that? What's to handle? Old versions of python2 packages are still in the online repos. The EOL means that there won't be any new releases to python. All of the old releases will still work though.
nitroll 7y ago
Distributing a container, virtual machine or something similar.
maweki 7y ago
Yeah, our bioinformatics department is already using anaconda extensively.

yrro 7y ago

Developers and scientists, in my experience, prefer to get the latest Python wheels from the Internet rather than reply on distributions to curate their packages. The consumers of distribution-provided packages is... other distribution-provided packages.

minusf 7y ago

python is 29 years old :}