Is there any consensus on how old of pip a package should support being installed by? Apologies if I have missed a doc somewhere.
I’m starting a new package and using pyproject.toml + setup.cfg. One developer wanted to add a setup.py to ensure that pip install -e works, which hadn’t been a problem for me. Turned out, they were using pip 20.x and I was using pip 21.x, and there have been recent(ish) improvements to pip’s support for editable mode.
While I used to test ranges of setuptools to ensure that I wasn’t adopting new features to the point of breaking older Python installations, PEP-517 has made that thankfully unnecessary. Before starting to do something similar with pip, I wanted to see if people have a range of pips they support (e.g., 2 years) or just make pip install --upgrade pip part of their installation instructions and call it a day.
I would say the only sane solution is to mention it in the contributing guide.
Note that it won’t be a problem if you package your project as a wheel, which supports an extremely wide range of pip. It only becomes a problem when one tries to install it from the source, and the contributing guide is the very place for the instructions.
Yeah, after writing this up, I’m a bit inclined to say our developer guidelines need to include pip install --upgrade pip. Everything else is something that ultimately needs to be maintained and eventually dropped; if you’re installing editable, you can upgrade pip.
Still curious to hear if people have gone the other way and if they have an argument for it.
As a pip maintainer, I’d strongly recommend upgrading pip to the latest version. We don’t support older versions (if you find an issue you’ll be asked to reproduce it in the current latest version). You should always be developing in a virtual environment anyway, so upgrading pip to the latest version shouldn’t be a problem. And you should be distributing your code as wheels, so your end users shouldn’t have any issues based on pip version.
Of course, there’s always exceptions and special cases. But that’s my general advice.
Don’t disagree with the advice, but isn’t it the case that pip itself may support a shallower range of old Python versions than some project developers feel like they need to? So some build envs may not be able to upgrade?
Pragmatically, the Python versions (where this will happen) are beyond end-of-life (EoL) versions of Python.
In my experience, this will typically happen in large-ish enterprises/instituions that don’t invest in migrating off to non-EoL versions of software. There are commercial vendors who provide the enterprise support that this usecase falls under and I’ll recommend such users work with them. Those Python versions are past the point where folks should expect community support for them (that’s kind of the point of them being EoL).
For the community-driven projects that with to work with a broader version of Python versions… well, things do not break on the day we drop support for older Python versions in newer versions of pip. It’s more of a slow rot. I’m pretty sure you can still install a substantial number of packages from pypi.org using pip 6.x or even pip 1.x. Not everything and, possibly, with some buggy behaviour. That said, if things break on an older version of pip with an older version of Python, don’t be surprised if pip’s maintainers say “you need to use the latest pip with an up-to-date Python installation”.
Yes-ish? python -m pip install -U pip will state that you’ve got no new upgrades on EoL versions, or get you to the newest version that supported that Python version.