Hacker News Reader

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.

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.”

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)

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...

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?

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.

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.

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.

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.

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.

> 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.

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.)

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.

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.

Interesting. I imagine what may have to happen is someone will (perhaps for profit) do all of the heavy lifting here so companies can use their server for old packages.

I get expecting that everyone will do this on their own, I just don’t think it will happen that way.

The default backend of pip is pypi. Pypi does not have a policy of removing previous releases (though package authors do have the ability to do this I believe). There are packages going back a really long time. You can find releases for Python 2.6 (EOL 2013) that were published in 2012 still on pypi (and accessible by pip).

In addition, paid extended support for Python 2.7 already exists from 3rd party vendors (I know of ActivePython) - Python 2 EOL just means you don't get free updates and supports.

PyPI may exist and hold old packages, but even that will eventually bitrot, and the API that the old version of pip uses to download files may no longer exist in the future (as an example).

For those cases you will want to make sure you have a local mirror.

That's correct, and I've verified it with modern versions of pip for Python 2.7 and 3.x. `pip2.7 install -U pip` just grabs pip 20.3.4 and installs it, ignoring pip 21.0.

pip and the legacy easy_install both access the "simple" list for a package when determining download options. This is a basic HTML page with links to all public versions of a package. Here's pip's: https://pypi.org/simple/pip/

These links contain Python version specifier information, which pip can use to select an appropriate version. For pip 21.0, that specifier is ">=3.6", so any modern pip will know it can't be used on a Python prior to 3.6. It will therefore fall back to the nearest version that provides a compatible specifier.

Looks like this was implemented starting in Pip 9.0 (at the end of 2016). From experience (my product is written in Python), there are plenty of enterprise installs that still use much older versions of pip than this. Those will grab pip 21.0 or newer (I just confirmed with a copy of pip 8).

I know for us, that'll be important to document. We still support Python 2.7 in part due to slow-moving enterprise installs, and I'm sure we're not alone in that. So geofft's example for forcing installs to <21 is exactly what a not-insignificant number of people will ultimately need to do.

Thanks for testing! And just to rephrase for others, this is a one-time (per environment/per virtualenv) thing - you want to upgrade pip to a version new enough to know not to upgrade too much, and then you're fine. Once you run the command I gave, a later "pip install -U pip" will keep you on 20.x and not upgrade to 21.

Don't forget about native dependencies. Any Python module that embeds native libraries needs to remain binary compatible with the host system. And because Python doesn't control this in anyway whatsoever, it's a lottery if things break on a current system, let alone an obsolete virtualenv one where the chances are even higher.

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?

If history tells us anything, the forcing function will come in the form of lots of noise once deployments begin to break.

I don't understand: why can't people just use the last version of Pip that supports Python 2?

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.

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.

You can point pip to whatever URL you want, and APIs use versioning.

There isn't a separate set of servers. The same servers (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.

They can, the people here acting like pip is banned from python 2 don't seem to understand much about python or software.

edit: wrongness

> New deployments will break once pip is updated.

No, they won't.

> The error here is you think the people doing this even have programmers to port to 3.x or admins with the wherewithal to make sure an older version of pip is used.

What wherewithal does that take? PyPI will just provide the last version of pip that supports Python 2. It takes no extra effort to not install a Python 3 version of pip on Python 2.

> Nobody wants to keep Python 2.x in use or force the Pip maintainers to keep 2.x support.

I'm sure there are people who do want to do the former. And they can, but it has no bearing on the latter.

Why won’t new deployments break? If they are using ‘pip’ to install 2.x libraries, my understanding is it will now fail.

> Why won’t new deployments break?

Because the bundled pip with Python 2 is py2 compatible, and upgrading it from pyPI will get the last version that supports py2.

If you are using distro packages, no distro that packages py2 is going to package anything but a py2-compatible pip tied to it.

All this means is that there will be no new versions of pip for py2.

Thanks!

But then at some point a breaking change in the backing service could be introduced, thus breaking pip2.

Distros providing pip2 as part of their LTS will probably backport such changes.

Well, yes, it's possible some future change to pyPI could break pip, but that would also break all versions of pip before the change, so there'd have to be a large transition window (because pyPI is how you update pip, too, so if you break existing clients, no one can get the upgrade to the version that supports the backend changes), so that's not going to be sudden and without warning.

Better question, why can't people update their scripts to python 3? Is it that much of a chore? Genuine question, I've only ever used 3.

I've found 3 broad classes of code bases when migrating:

1. Trivial or easy. Probably started using best 2/3 compatibility practices easily on, or the nature of the code lends itself to 2to3.

2. Not able to switch without effort, but able to be slowly ported to 2/3 with six and the like.

3. Hopelessly intractable. Either too much bad practices in string handling, or tied to a legacy system. No way to port it without risking subtle bugs. Usually this is due to playing fast and loose with string types, even though we have known better since well before python 3.

Hell, several of our projects are stuck on pip 9 because our requirements files have dependency conflicts that 10+ choke on, but 9 installs the right combination of.