pip 19.2 dropped support for Python 3.4. Since setuptools’ and wheel’s latest releases still support Python 3.4 (which is now EOL 1), I’ve not constrained them in the get-pip.py generated for Python 3.4 in that PR. However, I’m not sure if we should publish this get-pip.py without a constraint.
Which makes me wonder, when will wheel and setuptools drop Python 3.4 support? Specifically, do we have a version number today to constraint “under” for the 3.4 compatible get-pip.py? If we do, I’ll be happy to add the relevant constraint and publish the bootstrap.pypa.io/3.4/get-pip.py file.
Note that we’ve not had any end-user come up and request for this compatibility helper yet – but we have published them in the past so we can probably continue to do so.
I think the point is that we now have a “frozen” get-pip.py specific to Python 3.4. It pulls in the latest setuptools and wheel, because both of those still support 3.4 (and there’s no benefit to the user in not pulling in the latest versions). But at the point when setuptools and wheel stop supporting 3.4, we’ll need to say “wheel<0.35.0” (or whatever). So I think the question is whether setuptools and/or wheel have plans that mean we can add that constraint now, based on a plan like “wheel will drop support for Python 3.4 in version 0.35.0”.
If you don’t have such a plan, I think we just have to wait till you do drop 3.4 support, and make the change then.
Actually, if & when setuptools/wheel drop support for 3.4, won’t it be sufficient for them to add “python_version > 3.4” to their metadata, and we won’t need to constrain at our end at all? Or am I getting the use of python_version wrong there?
I just wanted to have the versions if we know them, with the plan being to publish w/o constraints, if I get no response by end of this month or if a user files an issue on get-pip; whichever is earlier.
I can’t speak for the rest of the maintainers but I usually drop support for a Python version when:
I decide that support is not something I need to continue (some balancing between the difficulty I’ll be causing for downstream users and the inconvenience of supporting the old version).
I need or want a feature that is not available in the version to be dropped.
If there are 3.4-specific patches in setuptools, I’m fine with removing them and dropping support for 3.4, but in my experience if you’re maintaining support for 2.7, support for 3.4 basically comes for free (except maintaining the tests becomes more annoying - but that is a problem that I need to solve more generally anyway). If one of the other setuptools maintainers wants to drop 3.4 at some arbitrary point earlier than I would consider natural I won’t stop them, but I personally don’t have any specific plans to actively drop it, in which case the answer is probably “whenever we drop 2.7 support”, at which point we’ll probably drop 3.4 and 3.5 and possibly more depending on what’s EOL and what features we have shims or backports around.
