5 ms·

I have a background in systems engineering, working on a commercial operating system. I code in several languages. To me, it’s just a given that adoption extend

I have a background in systems engineering, working on a commercial operating system. I code in several languages. To me, it’s just a given that adoption extends the lifetime of something, even if it is not under active development. There’s a strange phenomenon with Python in particular, where it is upsetting for some reason to be told that Python 2.x will still be in use after we retire. To me this is just the natural way things work. There is so much stuff out there using Python 2.x where there’s no programmer around to do porting work and because things work, there’s no reason to invest. Normally when this sort of thing has happened to say, a language like VB, it doesn’t really matter because the end result is something compiled with a runtime. As long as the environment the app runs in has consistent behavior (app compat) there’s nothing to do. But with Python that isn’t precompiled you need the toolchain and dependencies. Python 2.x isn’t going anywhere, so I think Pip will ultimately have to keep and “freeze” support for Python 2.x, rather than not supporting it. If you are reading this and infuriated, perhaps ask some old hands you know, instead of taking my word for it. Flash is perhaps the closest example I can think of. Flash was “over” ages ago but browsers have had to keep support for an awful long time. I give their decision a week before they revert and come up with an alternative.

Wowfunhappy 6y ago
I agree with you insofar as, Pip made the wrong decision here, and they really should walk it back. But I don't think that they will. Who is going to make them?
- ianhanschen 6y ago
  If history tells us anything, the forcing function will come in the form of lots of noise once deployments begin to break.
- dmitryminkovsky 6y ago
  I don't understand: why can't people just use the last version of Pip that supports Python 2?
  - Wowfunhappy 6y ago
    I guess the question is whether the servers will stay up. I was assuming they would not. If they go down, it will be a really major headache.
    - dmitryminkovsky 6y ago
      My understanding is that Pip uses PyPI so, yeah, if PyPI changes their APIs/URLs, this last version of Pip that supports Python 2 will stop working and then deployments will start breaking.
      - zzzeek 6y ago
        You can point pip to whatever URL you want, and APIs use versioning.
    - geofft 6y ago
      There isn't a separate set of servers. The same servers (https://pypi.org https://pypi.org) are used for all Python versions, and they keep old versions of packages around. If everything works as it should (which, to be fair, it might not :) ), pip running on Python 2 ought to find the latest Python 2-compatible version of packages, including the latest Python 2-compatible version if itself if you ask it to upgrade itself. It's theoretically possible that the API used could change in a way that old versions of pip can't handle, but a) the API is super simple and there isn't a strong reason to do this and b) doing that would break the ability of old versions of pip to upgrade themselves - that is, for released versions of Python with bundled pip to work - so they're very unlikely to break the existing interface, even if they add a new one. Still, since PyPI is a free service with no support contracts, and especially because packages hosted on PyPI are uploaded by the individual volunteer authors who have the ability to delete old versions of their own packages, businesses who depend on Python 2 would be well-advised to download/mirror what they need locally to ensure continuity of business.
  - zzzeek 6y ago
    They can, the people here acting like pip is banned from python 2 don't seem to understand much about python or software.
monadic3 6y ago
> where it is upsetting for some reason to be told that Python 2.x will still be in use after we retire. Is this true anywhere? I know of some companies that still use it, but they can also certainly foot the bill for maintaining their own software.
geofft 6y ago
Old versions of pip do support Python 2.x. Nothing is preventing you from using them. There is also a straightforward way of "compiling" your code - install all your dependencies into a virtualenv, tar up that virtualenv, and untar it to the same path on the next system. I've seen this system used to work around pip and Python upgrade complexities that already exist, even within Python 2 alone, and it works fine. Then you're insulated from both changes to pip and changes to the actual packages you're trying to install from pip. Edit to answer your question because someone downvoted me and now HN is preventing me from replying: I don't think you'll need to do anything special. The common case, honestly, is that you already have some version of pip shipped with your system (e.g., you're using Python and pip from your OS) - just keep using that version, because by definition it's a Python 2-compatible pip. The official Python 2 binaries bundle a version of pip which is also by definition Python 2-compatible. If you need to upgrade pip for some reason, you might need to specify a version constraint on it, e.g. pip install -U 'pip<21' But you also might not, because there's a way for packages to declare what Python versions they're compatible with, and so pip can take that into account when deciding what to resolve. (The trouble is that very old versions of pip, such as those bundled with LTS-age OSes, don't know how to do that, so they're going to try to upgrade to the newest possible version of pip. Less-old versions of pip running on Python 2 should, I believe, not upgrade to an incompatible version.)
- ianhanschen 6y ago
  Would I have to do anything special aside from installing an older version? I’m not familiar with the back end of pip - in particular whether it talks to a package server or not.
  - X-Istence 6y ago
    It does talk to a package server, but you'll want to grab all the source code/wheels for the relevant packages before they are no longer available anyway, especially as many projects are no longer going to be available under Python 2.
    - ianhanschen 6y ago
joiguru 6y ago
Self contained containers (like singularity) have come up to fill this gap. Since a few years back we have started investing in creating these containers at the end of every project, as it is becoming increasingly hard to depend on dependencies remaining available online indefinitely.
- SOLAR_FIELDS 6y ago
  That is a fabulous idea. I would love it if that became the de facto for newly published scientific papers - here is the source code and here is the container that we used to run it. Ultimate reproducibility.
zzzeek 6y ago
Flash is a terrible example because there is literally no place for flash apps to go except be rewritten from scratch in some entirely different platform. Python 2 programs simply get ported to python 3. And we are already ten years into python 3, so yes, python 2 is going away at least as much as say Perl 4 or MySQL 3 or Oracle 7 has gone away. Which is pretty damn away. Also they aren't withdrawing pip from being available for python 2. You just use the older version of pip. Programs that need pips newer features won't install on python 2 anyway. Because it's really going away very quickly now.
- ianhanschen 6y ago
  It’s the closest example I could think of to draw on. This is a good example of what I was talking about. Python 2.x isn’t “going away very quickly now.”
- maxerickson 6y ago
  It's a fair bet that AIR will be supported until Ruffle gets fleshed out (Harman is taking it over). (AIR isn't an interesting solution for a big chunk of apps, but there's lots where moving out of the browser is fine)
- IlliOnato 6y ago
  AFAIK even the most modern Perl 5.32 runs Perl 4 programs just fine, so "porting" programs from 4 to 5 was "trivial" in the strongest sense. Perl 7 finally is going to break this compatibility, at least according to the current plan, but the "porting" still is supposed to be trivial, in most cases just adding a pragma or two. 27 years after Perl 5 was released...
macksd 6y ago
I've definitely worked on projects where people want to just have it working and leave it working until after I'm long gone. I've had clients that I'm sure are still on Java 6, CentOS 5, maybe older, and will be for years to come. But the Python communities I've interacted with seem to care deeply about the ecosystem, updated libraries, new features. Web apps, data science, etc. Is my experience here warped? Are there people here seeing Python get used for the kind of stuff that might live as long as Cobol without moving forward with the language?
- gbear605 6y ago
  I think the largest chunk of Python usage is what you’re talking about. But there’s still a significant number of people (and importantly, companies) just using it as a scripting language to move around and parse data or files. They’ve gotta do it with something after all, so why not Python. And like other people were saying, these are the types of scripts that don’t get updated.
- mplanchard 6y ago
  One of the companies I used to work at had a several million line python 2 codebase supporting their product stack. They have decided to stick with python 2 at least for the foreseeable future, because the work of porting to python 3 is seen as too expensive and risky. This is a company that sold for over $2 billion to a much larger, much more enterprisey company. I wouldn’t be even remotely surprised if they’re still on python 2 in another ten years.
- bcrosby95 6y ago
  For future projects, sure. For ongoing ones, maybe. For projects that are working I'm not touching... why? A tool is a tool. When I bought a new drill I used it to put together the playhouse for my kids rather than tearing down my fence just so I could put it back together.
lima 6y ago
> Python 2.x isn’t going anywhere, so I think Pip will ultimately have to keep and “freeze” support for Python 2.x, rather than not supporting it. More likely, enterprise vendors like Red Hat will maintain Python 2 + pip for a long time. The upstream project has no reason to do so and made the right decision to stop supporting legacy stuff.

Wowfunhappy 6y ago

I agree with you insofar as, Pip made the wrong decision here, and they really should walk it back. But I don't think that they will. Who is going to make them?

ianhanschen 6y ago
If history tells us anything, the forcing function will come in the form of lots of noise once deployments begin to break.
dmitryminkovsky 6y ago
I don't understand: why can't people just use the last version of Pip that supports Python 2?
- Wowfunhappy 6y ago
  I guess the question is whether the servers will stay up. I was assuming they would not. If they go down, it will be a really major headache.
  - dmitryminkovsky 6y ago
    My understanding is that Pip uses PyPI so, yeah, if PyPI changes their APIs/URLs, this last version of Pip that supports Python 2 will stop working and then deployments will start breaking.
    - zzzeek 6y ago
      You can point pip to whatever URL you want, and APIs use versioning.
  - geofft 6y ago
    There isn't a separate set of servers. The same servers (https://pypi.org https://pypi.org) are used for all Python versions, and they keep old versions of packages around. If everything works as it should (which, to be fair, it might not :) ), pip running on Python 2 ought to find the latest Python 2-compatible version of packages, including the latest Python 2-compatible version if itself if you ask it to upgrade itself. It's theoretically possible that the API used could change in a way that old versions of pip can't handle, but a) the API is super simple and there isn't a strong reason to do this and b) doing that would break the ability of old versions of pip to upgrade themselves - that is, for released versions of Python with bundled pip to work - so they're very unlikely to break the existing interface, even if they add a new one. Still, since PyPI is a free service with no support contracts, and especially because packages hosted on PyPI are uploaded by the individual volunteer authors who have the ability to delete old versions of their own packages, businesses who depend on Python 2 would be well-advised to download/mirror what they need locally to ensure continuity of business.
- zzzeek 6y ago
  They can, the people here acting like pip is banned from python 2 don't seem to understand much about python or software.

monadic3 6y ago

> where it is upsetting for some reason to be told that Python 2.x will still be in use after we retire. Is this true anywhere? I know of some companies that still use it, but they can also certainly foot the bill for maintaining their own software.

geofft 6y ago

Old versions of pip do support Python 2.x. Nothing is preventing you from using them. There is also a straightforward way of "compiling" your code - install all your dependencies into a virtualenv, tar up that virtualenv, and untar it to the same path on the next system. I've seen this system used to work around pip and Python upgrade complexities that already exist, even within Python 2 alone, and it works fine. Then you're insulated from both changes to pip and changes to the actual packages you're trying to install from pip. Edit to answer your question because someone downvoted me and now HN is preventing me from replying: I don't think you'll need to do anything special. The common case, honestly, is that you already have some version of pip shipped with your system (e.g., you're using Python and pip from your OS) - just keep using that version, because by definition it's a Python 2-compatible pip. The official Python 2 binaries bundle a version of pip which is also by definition Python 2-compatible. If you need to upgrade pip for some reason, you might need to specify a version constraint on it, e.g. pip install -U 'pip<21' But you also might not, because there's a way for packages to declare what Python versions they're compatible with, and so pip can take that into account when deciding what to resolve. (The trouble is that very old versions of pip, such as those bundled with LTS-age OSes, don't know how to do that, so they're going to try to upgrade to the newest possible version of pip. Less-old versions of pip running on Python 2 should, I believe, not upgrade to an incompatible version.)

ianhanschen 6y ago
Would I have to do anything special aside from installing an older version? I’m not familiar with the back end of pip - in particular whether it talks to a package server or not.
- X-Istence 6y ago
  It does talk to a package server, but you'll want to grab all the source code/wheels for the relevant packages before they are no longer available anyway, especially as many projects are no longer going to be available under Python 2.
  - ianhanschen 6y ago

joiguru 6y ago

Self contained containers (like singularity) have come up to fill this gap. Since a few years back we have started investing in creating these containers at the end of every project, as it is becoming increasingly hard to depend on dependencies remaining available online indefinitely.

SOLAR_FIELDS 6y ago
That is a fabulous idea. I would love it if that became the de facto for newly published scientific papers - here is the source code and here is the container that we used to run it. Ultimate reproducibility.

zzzeek 6y ago

Flash is a terrible example because there is literally no place for flash apps to go except be rewritten from scratch in some entirely different platform. Python 2 programs simply get ported to python 3. And we are already ten years into python 3, so yes, python 2 is going away at least as much as say Perl 4 or MySQL 3 or Oracle 7 has gone away. Which is pretty damn away. Also they aren't withdrawing pip from being available for python 2. You just use the older version of pip. Programs that need pips newer features won't install on python 2 anyway. Because it's really going away very quickly now.

ianhanschen 6y ago
It’s the closest example I could think of to draw on. This is a good example of what I was talking about. Python 2.x isn’t “going away very quickly now.”
maxerickson 6y ago
It's a fair bet that AIR will be supported until Ruffle gets fleshed out (Harman is taking it over). (AIR isn't an interesting solution for a big chunk of apps, but there's lots where moving out of the browser is fine)
IlliOnato 6y ago
AFAIK even the most modern Perl 5.32 runs Perl 4 programs just fine, so "porting" programs from 4 to 5 was "trivial" in the strongest sense. Perl 7 finally is going to break this compatibility, at least according to the current plan, but the "porting" still is supposed to be trivial, in most cases just adding a pragma or two. 27 years after Perl 5 was released...

macksd 6y ago

I've definitely worked on projects where people want to just have it working and leave it working until after I'm long gone. I've had clients that I'm sure are still on Java 6, CentOS 5, maybe older, and will be for years to come. But the Python communities I've interacted with seem to care deeply about the ecosystem, updated libraries, new features. Web apps, data science, etc. Is my experience here warped? Are there people here seeing Python get used for the kind of stuff that might live as long as Cobol without moving forward with the language?

gbear605 6y ago
I think the largest chunk of Python usage is what you’re talking about. But there’s still a significant number of people (and importantly, companies) just using it as a scripting language to move around and parse data or files. They’ve gotta do it with something after all, so why not Python. And like other people were saying, these are the types of scripts that don’t get updated.
mplanchard 6y ago
One of the companies I used to work at had a several million line python 2 codebase supporting their product stack. They have decided to stick with python 2 at least for the foreseeable future, because the work of porting to python 3 is seen as too expensive and risky. This is a company that sold for over $2 billion to a much larger, much more enterprisey company. I wouldn’t be even remotely surprised if they’re still on python 2 in another ten years.
bcrosby95 6y ago
For future projects, sure. For ongoing ones, maybe. For projects that are working I'm not touching... why? A tool is a tool. When I bought a new drill I used it to put together the playhouse for my kids rather than tearing down my fence just so I could put it back together.

lima 6y ago

> Python 2.x isn’t going anywhere, so I think Pip will ultimately have to keep and “freeze” support for Python 2.x, rather than not supporting it. More likely, enterprise vendors like Red Hat will maintain Python 2 + pip for a long time. The upstream project has no reason to do so and made the right decision to stop supporting legacy stuff.