Release 24.3

[pradyunsg]

Filing this eagerly, because I figure it can't hurt. :)

[pradyunsg]

I won't have bandwidth to take on this release cycle and also don't wanna be hoarding on the release manager responsibilities. 😉

[pradyunsg]

And, FYI: https://github.com/pypa/get-pip/pull/218#issuecomment-2310759449

[notatallshaw]

For anyone who is also a maintainer of resolvelib I'm waiting on a release (https://github.com/sarugaku/resolvelib/issues/159) to fix several known incorrect ResolutionImpossible errors.

And while I'm asking for things that affect pip but require other projects with overlapping maintainers: https://github.com/pypa/packaging/pull/794

[sbidoul]

I'm happy to take the RM hat for 24.3, unless anyone else wants to. I have very limited availability at the moment, so the release would be towards end October, mostly taking what is merged on main at that time.

[pfmoore]

If you'd prefer I can take it. My availability is also limited, but for me it's more unreliable, so it'll be a case of "you'll get the release when I have a free weekend". I'd also stick with just releasing what's on main - I'm happy to remind people of stuff on the 24.3 milestone, but I won't complete them myself.

Ping me if you'd rather I did it.

[kotborealis]

When will be 24.3 released? pip 24.2 still contains urllib3 1.26.18 which is affected by CVE-2024-37891 (GHSA-34jh-p97f-mpxf).

[sbidoul]

I'll have a look at what is in the 24.3 milestone soon.

Then I plan to release what is in main around October 20 or 27.

[pradyunsg]

@sbidoul I took the liberty of assigning this issue to you. 😅

[notatallshaw]

FYI, I've moved the issues which depended on a new resolvelib release and vendor to from milestone 24.3 to 25.0, as I reason here: https://github.com/sarugaku/resolvelib/issues/159#issuecomment-2404848946

[notatallshaw]

If 24.3 is the last version to support Python 3.8 I think it would be a big help, for a small number of users, if truststore released with https://github.com/sethmlarson/truststore/pull/157 and it was vendored by pip. Just on the intuition that old versions of MacOS might be using old versions of Python.

If at least pip 25.0 supports Python 3.8 I think it's less important.

[potiuk]

Comment from a side/user: agree with @notatallshaw. The worst that could happen is that users who are sticking with 3.8 will not be able to run 25.*. Which might incentivise them to upgrade Python.

I think it might be worthwile to add a warning - if someone uses < 25.* and they use Python 3.8, the "upgrade available" message could include the warning about using EOL Python and telling the user to migrate to higher version of Python as well. That would be a win-win for the ecosystem - encouraging people who are not even aware that Python 3.8 is already EOL.

I think it would also be great to agree general policy on which Python versions pip supports in general - and make it a "standard" approach for future migrations as well. This helped a lot in Airflow - we have now policies agreed on that and rather than discussing it, we jus follow the rule we agreed before (or if we want to change the rule, it's clear we need to start a discussion on it including justification for change).

[potiuk]

BTW. My proposal above means adding support / code to produce such message in the latest version of 24.*. of course.

[hugovk]

I think it would also be great to agree general policy on which Python versions pip supports in general - and make it a "standard" approach for future migrations as well. This helped a lot in Airflow - we have now policies agreed on that and rather than discussing it, we jus follow the rule we agreed before (or if we want to change the rule, it's clear we need to start a discussion on it including justification for change).

The policy is at https://pip.pypa.io/en/stable/development/release-process/#python-support-policy:

Python Support Policy

pip supports CPython versions that are not end-of-life. Older versions of CPython may be supported at the discretion of pip maintainers (based on criteria such as download statistics on PyPI, Python versions supported by the vendored dependencies and maintenance burden).

[sbidoul]

If 24.3 is the last version to support Python 3.8 I think it would be a big help, for a small number of users, if truststore released with sethmlarson/truststore#157 and it was vendored by pip. Just on the intuition that old versions of MacOS might be using old versions of Python.

If at least pip 25.0 supports Python 3.8 I think it's less important.

@notatallshaw I'm not comfortable with including an unmerged trusttore PR (assuming our vendoring policy would allow it). Can you post that comment on https://github.com/pypa/pip/issues/12989 so we keep track of that there?

[notatallshaw]

I'm not comfortable with including an unmerged trusttore PR (assuming our vendoring policy would allow it). Can you post that comment on #12989 so we keep track of that there?

100% agreed, I didn't mean to imply that, more that if truststore is able to release with that PR merged it would be a great help and would make it easier to consider dropping support for Python 3.8 in 25.0. I did mention it in https://github.com/pypa/pip/issues/12989#issuecomment-2408722710 but I'll add something that's more explicit.

[notatallshaw]

Actually, I withdraw my comments about truststore, I got confused and thought it was doing openssl 1.1.1+ detection, but I see it's actually doing Python version detection: https://github.com/sethmlarson/truststore/blob/v0.9.2/src/truststore/init.py#L5

So any vendor of truststore is irrelevant to Python 3.8 and 3.9. Sorry for the noise.

[pradyunsg]

assuming our vendoring policy would allow it

It does not.

[WilliamRoyNelson]

Is the plan still to release what is in main around October 27th? I know CVE-2024-37891 (which will be fixed by the updated urllib3 package in main) doesn't seem like an incredibly serious problem, but because pip is so ubiquitous, it's probably a good idea to cross that off the list.

[notatallshaw]

Is the plan still to release what is in main around October 27th? I know CVE-2024-37891 (which will be fixed by the updated urllib3 package in main) doesn't seem like an incredibly serious problem, but because pip is so ubiquitous, it's probably a good idea to cross that off the list.

Yes, @sbidoul will decide exactly when to release, but pip 24.3 will be released soon: https://pip.pypa.io/en/stable/development/release-process/#release-cadence

It will be a cut of main which is currently on urllib3 1.26.20 (https://github.com/pypa/pip/blob/main/src/pip/_vendor/vendor.txt), which includes a fix for this CVE: https://github.com/urllib3/urllib3/blob/1.26.x/CHANGES.rst

[hugovk]

It would be nice to include the vendored truststore update (issue: https://github.com/pypa/pip/issues/12901, PR: https://github.com/pypa/pip/pull/13041), so it can be included in an ensurepip update for the next CPython releases:

• 2024-11-19: 3.14.0a2
• 2024-12-03: 3.12.8
• 2024-12-??: 3.13.1

Edit: I now see it's already been added to the 24.3 milestone 👍

Thanks!

[sbidoul]

Yep, will do. It is already in the 24.3 milestone.

[sbidoul]

• [x] prepare https://github.com/pypa/pip/pull/13044
• [x] publish to PyPI
• [x] push tag
• [x] update get-pip https://github.com/pypa/get-pip/pull/224
• [x] release announcement https://discuss.python.org/t/announcement-pip-24-3-release/69350
• [x] CPython PR: https://github.com/python/cpython/pull/126805

[potiuk]

Would it be possible to post here when a candidate/beta is ready for testing ?

I will be happy to run our extensive checks on 24.3 in Airflow - while most of our CI runs with uv for speed, we can switch it to pip and run complete set of tests including eager upgrade and a number of other cases (and with Airflow's complexity it stretches pip a bit) - just to help with testing.

It does not have to be released in pypi - if there is a branch or tag that is "ready for testing", we can modify our CI to install from GitHub directly rather than from released package.

[sbidoul]

@potiuk we won't make a beta for 24.3, but you can test with the main branch, as it will become 24.3 later this week end.

[potiuk]

@potiuk we won't make a beta for 24.3, but you can test with the main branch, as it will become 24.3 later this week end.

Will do and report it.

[potiuk]

Running here: https://github.com/apache/airflow/pull/43395 -> I will likely have to do small modifications, but eventually I will turn it into one-switch-testing for the future.

[potiuk]

Update: looks good so far :)

[sbidoul]

Heads-up: there was a little issue with the get-pip CI in https://github.com/pypa/get-pip/pull/224 which I resolved with https://github.com/pypa/get-pip/pull/224/commits/90f1b115be1f9b9ccfef8f4618dfef12737a7e36 in order to not block the release process.

[sbidoul]

All done. I'll do the CPython PR in a few days.

[xmatthias]

@sbidoul I'll take the liberty to point out #13046 (not sure if you're monitoring for all issues in this repo) - which is an issue that popped up about an hour ago - and is caused by the new pip release.