On behalf of the PyPA, I am pleased to announce that the pip team has just released pip 23.0!
As a reminder, the pip project follows Calendar Versioning – 23.0 is not a “major” version release with backwards incompatible changes but rather the first release of the year 2023. You can read more about our versioning, deprecation policy, and release process here.
pip inspect and pip install --report formats are bumped to version 1 and are stable.
If keyring is not installed in the environment but is available on PATH, pip will uses it.
Notably, this allows keyring installed using pipx to be used by pip.
A regression that reduced cache reuse compared to older versions of pip has been resolved.
This release contains many other usability improvements, enhancements, and bugfixes. This release, notably, has multiple under-the-hood improvements to pip. You can find the full list in our changelog.
Thanks
As with all pip releases, a significant amount of the work was contributed by pip’s user community. Huge thanks to all who have contributed, whether through code, documentation, issue reports and/or discussion. Your help keeps pip improving, and is hugely appreciated.
@pradyunsg Congrats. The changelog doesn’t say (unless I missed it) but this release does unblock the deprecation of imp and related APIs from Python 3.12, doesn’t it? Who generally updates ensurepip in the CPython repo?
It’s usually the pip developers, but (I think) we generally wait a little bit after the first release of a major version to ensure there’s no critical breakage in it. Anyone else can also do it if they want to include the new pip version in a certain CPython (pre-)release.
Stall things a little bit and you can merge it yourself
I think we’re generally fine to take the update in 3.12 straight away, provided we also get any bugfix releases quickly as well. It’s not until RC that we’ll want to lock it down.
But hold the updates in earlier versions for a bit until you’re confident (generally we’d go to the pip team and ask whether the current release is stable enough to merge, so that step can be saved now).
I normally create the CPython PR pretty much straight away. But that’s just me. And I’d happily merge a PR from @pradyunsg if he wants to have a last look at the “not a core dev” experience
But realistically, there’s not normally any particular urgency, so it’s a bit of a “get to it when you can” thing. If the timing affects CPython, that’s an unusual situation.
Well, the main reason I didn’t do it immediately was that it was close to midnight, and I had work the next morning. I’ll come around to the CPython PR after my work day is over, assuming pip’s issue tracker doesn’t have folks with a pitchfork pointed at me.
While I have peoples’ attention (), I’d appreciate more on
Pretty much. The main issue would be that the next patch/alpha release will have a version of pip that’s slightly older – I reckon that’s fine.