Build wheel for Python 3.12 beta

[hugovk]

We've been testing Python 3.12 since alpha (#571), and it's now in beta.

The 3.12 release manager said:

We strongly encourage maintainers of third-party Python projects to test with 3.12 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2023-07-31). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.12.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.12 as possible during the beta phase.

I think it would be a good time to also build wheels for 3.12. This will help others, who depend on UltraJSON, to more easily test and prepare their libraries.

It is possible for ABI changes to occur, but these wheels should also be considered beta, and we can easily put out new releases for new beta (or add a build number and upload to the same release).

---

We're using https://github.com/pypa/gh-action-pypi-publish directly to upload sdists, but twine for the wheels. I've switched the wheels to https://github.com/pypa/gh-action-pypi-publish as well, because I'd like to improve security by switching over to using a "trusted publisher" that makes use of short-lived tokens instead of a persistent one (which lives on my personal account) and is saved in repo secrets.

More info:

• https://github.com/pypa/gh-action-pypi-publish#trusted-publishing
• https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

But to configure this on PyPI, I'd need "owner" access rather than "maintainer".

@cgbystrom Please could you give me owner access at https://pypi.org/manage/project/ujson/collaboration/?

[codecov-commenter]

Codecov Report

Merging #594 (a4ad811) into main (092df91) will not change coverage.
The diff coverage is n/a.

❗ Current head a4ad811 differs from pull request most recent head ffd17da. Consider uploading reports for the commit ffd17da to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@           Coverage Diff           @@
##             main     #594   +/-   ##
=======================================
  Coverage   91.66%   91.66%           
=======================================
  Files           6        6           
  Lines        1944     1944           
=======================================
  Hits         1782     1782           
  Misses        162      162           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[hugovk]

Also:

I didn't add the 3.12 Trove classifier yet. We could wait until full release in October, but some other projects have added it already:

• 7 in the top 360: https://pyreadiness.org/3.12/
• 1,060 in total: https://pypi.org/search/?c=Programming+Language+%3A%3A+Python+%3A%3A+3.12

Shall we wait or add it now?

[bwoodsend]

I didn't add the 3.12 Trove classifier yet. We could wait until full release in October, but some other projects have added it already:

I think if we have wheels, we might as well have trove classifiers. I'm not particularly fussy either way though.

[hugovk]

Let's merge, we can do the PyPI trusted publisher later, it's neither blocking this nor urgent.

[hugovk]

Ah right, https://github.com/pypa/gh-action-pypi-publish failed on Windows and macOS:

Run pypa/gh-action-pypi-publish@release/v1
Error: Container action is only supported on Linux

https://github.com/ultrajson/ultrajson/actions/runs/5171049638/jobs/9314350206

Well, the next 3.12 beta is due out tomorrow, 2023-06-06, and I was planning on waiting for that (and cibuildwheel updates etc.) to make a release with the 3.12 wheels.

Some options:

• Short term, we could switch back to twine for the native ones.

• And later, we can do something like uploading artifacts from native, and do the PyPI upload in the final step with the sdist.

• Or, as we're already uploading all the wheels from native + QEMU, shall we instead do all the uploads from the final step?

I think this final option is simplest. I seem to remember there being a much bigger variance in build times earlier, but now they're fairly close to each other. It would also mean if any of the individual jobs failed, nothing would be uploaded, which seems better than a partial PyPI release?