3 ms·
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 al
by 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 agoWould 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 agoIt 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 agoInteresting. 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.
- icegreentea2 6y agoThe 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.
- X-Istence 6y agoPyPI 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.
- chipx86 6y agoThat'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/ 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.
- geofft 6y agoThanks 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.
- rleigh 6y agoDon'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.