Release 23.0

[pradyunsg]

[pradyunsg]

Well, happy new year folks!

We're due to make a release this month and, well, it seems like we do have a bundle of changes that we'd want to ship out. :)

As usual, any takers for the RM role? I'm happy to pick that up, if no one else has bandwidth.

[potiuk]

I guess as a user I cannot help with the release, but I can offer help in testing the release in Apache Airflow case.

We have quite a few cases and one of the most complex dependency mechanisms out there and as long as some version is in the state that is ready to "test" - happy to test it there.

I know (after the discussion in #10882) that pip maintainers are not in favour of release candidates, but if there is time where you can say "here the branch or tags is ready to test" I just opened a PR modifying our CI framework to allow for "github URL" installation mechanism for pip in our toolchain in Apache Airflow:

apache/airflow#28697

As long as there is something "ready" to test I will watch this issue and will be happy to run it through the full set of tests.

I could also do that in main and even run our toolchain daily or weekly or whatever, but I am not sure if this is in any way actionable - not sure if you would like to be flooded by "main" issues which are just a byproduct of being main and possibly containing known issues.

With the above modifications merged I could also run tests with your main as regularly as you think makes sense - just let me know - I'd love to help pip testing in whatever way Airflow can help, since we are very heavy users and I think we are utilsing quite a lot of pip capabilities and complexities, so this might be helpful also for you - especially that it will be run on Airflow's resources and I might be doing pre-vetting of those problems to see if they are "worthy" of reporting.

Just to show an example how it can be helpful - because of our big number of dependencies, we've been successfully doing this for other projects that we depend on and it helped those project by us (myself as I am mostly on a watch there) quickly catching and reporting issues like that that our "canary" runs on CI detected pretty much immediately after they were released (but we've never been doing it for main for them):

Examples:

• New Dask 2022.10.1. release broke Airlfow's integration tests dask/dask#9609
• Missing ciso8601 in Pnnotdb 0.4.7 python-pinot-dbapi/pinot-dbapi#47
• Sphinx 5.2 incompatibility readthedocs/sphinx-autoapi#352
• Astroid 2.12 breaks sphinx autoapi (at least for Airflow) pylint-dev/astroid#1708
• Lack of sdist in PyPI for 1.4.0  jpype-project/jpype#1069

[pradyunsg]

Alrighty, no one said anything over the last few days so I'll self-assign myself. :)

[dnicolodi]

@pradyunsg I would be happy to help. Please let me know if there is anything I can do to help with in preparing the release.

[pradyunsg]

Hold off on merging things today folks; I'll be cutting a release in ~8 hours.

[dnicolodi]

@pradyunsg Can you please consider merging #11740 before the release? I would very much like to do not have pip broken on Debian till the next release in a few months. Thank you very much!

[pradyunsg]

• 23.0 is on PyPI.
• get-pip.py is WIP updated.
• https://discuss.python.org/t/announcement-pip-23-0-release/23342 is up.

[pradyunsg]

I'm inclined to cut a bugfix release with:

• Do not crash in presence of misformatted hash field in direct_url.json #11779
• Ignore PIP_REQUIRE_VIRTUALENV for pip index #11671
• Implement --break-system-packages for EXTERNALLY-MANAGED installations #11780
• Reconcile computation of isolated build environment paths #11740

Any concerns with this?