Announcement: pip 23.2 release!

On behalf of the PyPA, I am pleased to announce that the pip team has just released pip 23.2.

This is the third release of pip for the year 2023. You can read more about our versioning, deprecation policy, and release process here.


  • We fixed a bug that meant pip could not use PEP 658 metadata served by a package index. As a result pip will now use the metadata served by PyPI, hopefully improving download speeds significantly for projects with large wheels.
  • Deprecate support for eggs for Python 3.11 or later, when the new importlib.metadata backend is used to load distribution metadata.
  • Deprecate legacy version and version specifiers that don’t conform to PEP 440.
  • freeze no longer excludes setuptools, distribute, and wheel from the output when running on Python 3.12 or later, where they are not included in a virtual environment by default.

This release contains many other usability improvements, enhancements, and bugfixes, as well as upgrades to our vendored libraries. You can find the full list in our changelog.


As with all pip releases, a significant amount of the work was contributed by pip’s user community. Many thanks to all who have contributed, whether through code, documentation, issue reports and/or discussion. Your help keeps pip improving, and is hugely appreciated.

Paul Moore

(Edit: Added the note about PEP 658 support)


Is anyone assembling a list of popular packages that will be affected by this? It doesn’t seem to cause a problem for any of the third-party libraries I normally use (and for my own projects I have, AFAICT, been conforming for as long as I have been packaging and distributing), but I have already heard from people complaining about not knowing what to do about the deprecation notices.

Why does there need to be a list? The deprecation message states the project that has a deprecated version/specifier, just report the problem to them. They are the ones who need to fix it.

The last release uploaded to PyPI with a non-PEP 440 version was in January 2015 [1], so I doubt any projects/users will realistically be affected by this. If people are seeing deprecation notices, it’s probably because they’re consuming private packages from private indices, not popular projects from PyPI.

  1. ↩︎


Hmm. This bothered me enough to go back and look it up.

The specific complaint I saw referred to packages/versions distro-info 1.1build1 and python-debian 0.1.43ubuntu1. This was in a now-deleted Stack Overflow question; I have permissions to view it, but the link wouldn’t be useful here, and it seems at least unethical to reproduce the text off-site.

PyPI only appears to have distro-info up to 1.0, while python-debian is at 0.1.49; the only non-PEP440 version I see on PyPI is 0.1.21-nmu2. It seems like these packages are part of an up-to-date Ubuntu installation (i.e. as a core part of the distro, but then it isn’t clear to me why Pip would be involved in installing them).

Maybe the ubuntu developers have a separate index for system packages?

Looks like this is which is slowly getting fixed in newer distros.


No, but they’re building packages themselves in a manner that does not perform this validation today and would be printing a deprecation warning. They’re never putting them in a package index, and instead ingesting them within their own packaging system (DPKG/apt).

For anyone interested in finding out more about how/why/what is being done about this on the Python packaging tooling side, and what the timelines for the changes involved have been, see:

pip is the last project in a long tail of Python’s packaging tooling that have either been rejecting or warning about such versions, with this being disallowed nearly a decade ago on public PyPI uploads (as Dustin noted with the Jan 2015 version).


Pip 23.2.1 has just been released, with a fix for a bug in the “fast metadata” code when used with the legacy resolver. The fix simply disables the “fast metadata” code when the legacy resolver is in use.