Add a time limit to Python version support #12450
Conversation
|
Given the suggestion in #11944 that the download numbers are kept high by large institutional numbers, is there any actual value in having a trigger based on download counts at all? It feels like it would be more honest if we simply switched to follow CPython EOL dates directly. (Although if we did that, I wonder what the reaction would be from LTS Linux distributions, for example). |
|
I'd be on board for that. I'll update this PR to align with CPython's EOL exactly, rather than with an offset. |
pradyunsg
force-pushed
the
add-time-limit-to-py-version-support
branch
from
1f8976e
to
2fb63f6
Compare
Currently, we are supporting Python version until their usage falls low-enough. This worked well, when we had fewer users and Python's sliding window moved slower. We have, however, not used the threshold for the last few Python releases and our metrics for determining usage levels are not particularly robust against being overrepresentative of certain usage patterns (we're seeing this in the current usage numbers). Aligning with CPython helps ensure that the maintainers of pip aren't subsidising the cost of EOL Python versions indefinitely.
pradyunsg
force-pushed
the
add-time-limit-to-py-version-support
branch
from
2fb63f6
to
8212d9a
Compare
|
🤷 I'm still more interested in the question of what we gain by desupporting than fine-tuning the policy, but I'm not going to block this either way... |
|
One gain is ease of vendoring libraries, I remember Pip is stuck on vendoring urllib3 2.0 (but I didn't remember the specifics). It seems common in the Python ecosystem to either follow the Python EoL schedule or to follow the Numpy supported Python schedule. There are Python versions after 3.7 that introduce new syntax, such as walrus operator, match statement, type syntax. If vendored libraries choose to use those because they don't support EoL Python version then Pip would need to decide how to vendor those. |
|
Perhaps link to https://devguide.python.org/versions/, where people can find CPython EOLs? One benefit of using a set schedule is it helps people plan ahead, and there's no surprises when versions will be dropped. |
Based on discussion in #11944
This has a nice side-effect that we can consistently drop Python version support in our
YY.0releases, if we wanted to be lazy and not check PyPI download version numbers. :)