Drop support for Python 3.8 #12989
Assignees
Labels
type: maintenance
Related to Development and Maintenance Processes
Comments
notatallshaw
added
type: feature request
|
Paging @hugovk for the pip downloads stats. My gut reaction is that dropping support for Python 3.8 right after EOL may be a bit too painful. |
|
From https://hugovk.github.io/pypi-tools/charts.html#pip:
PyPI downloads for the last 30 days, for all versions of pip shows 9.52% with Python 3.8: ❯ pypinfo --all --percent --markdown pip pyversion
Served from cache: False
Data processed: 5.73 GiB
Data billed: 5.73 GiB
Estimated cost: $0.03
Limiting to only downloads of pip==24, with the reasoning that users of pip==24 are most likely to upgrade to 24.3 and excluding those who never upgrade anyway, shows 1.35% for Python 3.8: ❯ pypinfo --all --percent --markdown pip==24 pyversion
Served from cache: False
Data processed: 7.45 GiB
Data billed: 7.45 GiB
Estimated cost: $0.04
A 3.7 asidePython 3.7 has already been dropped, but Amazon Linux is still responsible for all the 3.7 downloads: ❯ pypinfo --limit 20 --percent --markdown pip==24 system distro pyversion
Served from cache: False
Data processed: 13.65 GiB
Data billed: 13.65 GiB
Estimated cost: $0.07
|
Does that mean pip versions |
|
Hmm, I thought it meant all 24.0: 40.7m (last to support 3.7)
24.1: 0.2m
24.2: 167.2m
|
|
I realize that in the case of Python 3.7, we were in favour of dropping support for it promptly, but I really don't see any worthwhile benefits from dropping 3.8 soon. It'd be nice to fix some bugs in the 24 series for 3.8 users, and then we can revisit the question closer to 25.0. For context, I grepped all of pip's source code for references to Python 3.8 for any code that we could clean up and I only got one hit in the resolvelib glue: pip/src/pip/_internal/resolution/resolvelib/found_candidates.py Lines 28 to 39 in 348c428 Of course, starting in Python 3.9, many built-in types are now subscriptable for typing purposes. Other than that, I'm not aware of anything major we'd be gaining. Python 3.9 is indeed the real kicker as that unblocks the upgrade to urllib3's 2.x series. (And then Python 3.10 as that's the last version to use the old metadata backend.) |
Can you please check for 24.1.2, both 24.0 and 24.2 didn't have patch releases, but 24.1 had two followup patch releases, and I'm guessing by the fact you're seeing 24.1 as 100x less downloads it's because the numbers are only for 24.1 and not 24.1.1 or 24.1.2: https://pypi.org/project/pip/#history |
From my point of view I think the only compelling reason to drop older versions of Python is to support any vendored packages that don't 100% support older versions of Python. And in this case I think the most important example is urllib3 2.0, which pip can not vendor until it drops Python 3.9. And the longer pip waits for Python 3.8 to be dropped the more of a shock it will be to users if Python 3.9 is dropped quickly. I don't think there is significant technical debt in pip from supporting older 3.x versions, and if it wasn't for pip needing to vendor libraries I would consider it appropriate to support old versions of Python until the CI broke. |
|
I think a reasonable cutoff is pip 24 is the last series to support Python 3.8. Not particularly meaningful, at least hey we can point "it's a major release, y'all happy semvar folks?!" I'm only half-joking :) |
Yep, that sounds about right, 24.1.2 is bigger but still fairly low: 24.1.1: 0.2m
24.1.2: 0.5m
|
That's fascinating how starkly different orders of magnitude the 24.1 releases are, it really makes me wonder what dominates download numbers and how useful they actually are from a project maintenance perspective.
I guess we take a look again closer to the 25.0 release? And if there isn't a truststore release and vendor before 24.3, as I mention in #12941 (comment), I think it would be quite helpful to some users to do one more Python 3.8 release with that new version of truststore. |
Yeah, I didn't see much either, but there are a lot of typing changes from Ruff/pyupgrade, something like 200 files and 1,200 lines, for example: https://github.com/pypa/pip/compare/main...hugovk:pip:rm-3.8?expand=0 |
Closed
|
Small comment from the user point of view. There is one more benefit from dropping 3.8. It's good way to help the ecosystem to move to Python 3.9 quicker. Even if pip itself is not affected, generally moving faster to non-EOL version of Python is good for multiple reasons - including security reasons. Imagine someone finds a critical security issue in Python in March 2025 and it gets fixed only in 3.9+. People who would stil be using Python 3.8 are vulnerable, and with security, it's important to limit the damage - so the less number of people still use Python 3.8, the better. As the default frontend used by many - |
|
I don't think pip should be pushing users to upgrade their Python installation - that feels backwards to me. I'm happy with our current policy of dropping support for Python versions when usage (as measured by pip download figures for that version) gets low enough that we expect the impact to be minimal. If the core Python team wants to push users to adopt newer versions faster, that's something they should do themselves. |
Sure - if that's the maintainer positions, I just thought it's worth to share that perspective where the whole ecosystem works together - I am now working with @sethmlarson on Airflow Supply Chain security improvements and reviews with the goal of making it then possible to apply to the whole PyPI ecosystem gets benefit of what we do, and recently gave a talk at Airflow Summit Keynote about it called "Security United" where together with Alpha-Omega we stressed how important it is where everyone works together on improving security, regardless if it is "our" or "their" problem, so I thought I might mention that having But if maintainers of |
|
It’s not so much a matter of not our problem, more a case that I’d want the core team to take the lead on any effort to get people to upgrade Python more aggressively. |
Sure. I acknowldged your right to make that decision, provided different perspective and have shown and example where others think differently and act for the good of the whole ecosystem in principle. Just so you see this can be at least taken it into consideration when you make decisions about your project. No more, no less. But of course it's you who decide where you spend your energy and efforts, and you have the right to do so - it's your call of course not mine. And it's not that I agree or disagree with it, it's not for me to decide, still I think it's worth knowing that others are thinking differently. |
|
FWIW, I should also note that what the numbers look like for Last I checked, that was on the order of terrabytes for the query but I don't remember the timescale I was querying (point is:I couldn't do it on the free tier). It does make sense that these costs match with pypi.org's exponential growth tho. |
|
I have a local patch that drops Python 3.8 support with pyupgrade and manual clean-up done. I haven't PRed it as it needs a bit more work, and it's going to be very merge-conflict prone so I'll wait until we decide on a timeline. |
Open
|
@hugovk if it isn't too burdensome, could you share the updated statistics? |
|
Sure, which ones in particular?
Here's an attempt at this for the past 7 days: ❯ pypinfo --test --days 7 --percent --markdown pip pyversion installer installer-version system
SELECT
REGEXP_EXTRACT(details.python, r"^([^\.]+\.[^\.]+)") as python_version,
details.installer.name as installer_name,
details.installer.version as installer_version,
details.system.name as system_name,
COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -8 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
AND file.project = "pip"
AND details.installer.name = "pip"
GROUP BY
python_version, installer_name, installer_version, system_name
ORDER BY
download_count DESC❯ pypinfo --days 7 --percent --markdown pip pyversion installer installer-version system
Served from cache: False
Data processed: 2.91 GiB
Data billed: 2.91 GiB
Estimated cost: $0.02Only rows containing 3.8
First 100 rows
Whole thing: 1,789 rows
|
|
Adding all of the Python 3.8 rows, Python 3.8 accounts for ~8.3% of all downloads using pip.
Taking a brief look at the data, the 3rd row is likely caused by the fact 23.0.1 is the newest pip bundled with 3.8 (from the last security source release). The 4th row is probably due to Ubuntu 20.04 which ships with Python 3.8 and pip 20.0.2. I can't explain the 2nd row, however. (The last 3.8 bugfix release, Python 3.8.10, ships pip 21.1.1, not 21.0.1.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Python 3.8 support, from the Python Foundation, is ending in a few weeks: https://endoflife.date/python
This is to track ending Python 3.8 support, see 3.7 end: #11934 and #11944
There is motivation as pip will not be able to vendor urllib3 2 until Python 3.9 support is dropped: #12857. Which contains bugfixes/features that will not be backported.
Code of Conduct
The text was updated successfully, but these errors were encountered: