Release 24.0

[mayeut]

Please cut a new release so that downstream projects can leverage the new PEP 703 compatibility (no-gil, free-threaded).

xref: pypa/pip#11715 (comment) / pypa/pip#12300

[markdryan]

It would also be great to have the riscv64 commit included in an official release as well.

[dralley]

The topic of a manylinux_2_34 base image for building packages has also come up, it would be nice to support that if the effort is ready in time

pypa/manylinux#1575

[brettcannon]

@pradyunsg if you want help w/ this I am still hopefully around until mid-March, but starting Feb 28 the baby can officially show up any day.

[colesbury]

It'd be great if we could cut a new packaging release soon. It's a blocker for getting pip to work with the free-threaded builds.

[hugovk]

I was just about to post about this :)

We'll need a packaging release before next month, so it can be vendored in the April quarterly release of pip (24.1), so that pip can be included in the Python 3.13 beta in May, so we can get feedback and fixes before 3.13.0 final in October.

pip's July release (24.2) is a bit too late: the final 3.13 beta is 2024-07-16 and first release candidate is 2024-07-30. And it'd be good to keep some buffer in case of updates needed in pip 24.2 (or vendored dependencies).

Please let us know if there's anything we can help with!

[notatallshaw]

It'd be great if we could cut a new packaging release soon. It's a blocker for getting pip to work with the free-threaded builds.

I've only been loosely following along, but isn't the issue pip has not vendored a new version of packaging? If that's the case then a release won't help until that vendoring happens.

There is an open PR since September last year, but is still missing work for it not to just break pip on many common installs.

On that note, I feel pip maintainers should be aware, comparing to uv, they are supporting a subset of legacy version and specifier patterns, presumably the ones they most commonly see. Even then I've seen several issues reported to them of users complaining non-compliant versions and specifiers not working, even though pip is throwing a warning for the same packages.

[hugovk]

I've only been loosely following along, but isn't the issue pip has not vendored a new version of packaging? If that's the case then a release won't help until that vendoring happens.

#728 needs a release, to add support for the t wheel tag, used to denote PEP 703 free-threaded builds. Otherwise things fail like:

      AssertionError: would build wheel with unsupported tag ('cp313', 'cp313t', 'linux_x86_64')

Then that needs vendoring in a pip release.

packaging will also need to be vendored in a wheel release: pypa/wheel#585

[pradyunsg]

I'll make time for doing this in this week. :)

[pradyunsg]

https://pypi.org/project/packaging/24.0/