As I was inspecting the repo, I noticed a few outdated, deprecated, discouraged practices and vulnerability surfaces regarding $sbj. So this is my attempt to document them.

• Invoking setup.py directly has been deprecated some time ago @ https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html; and it'd been discouraged during like half a decade before. It's still fine to use it as a config for the setuptools backend. But please, don't invoke this module. You can move most of the file contents to setup.cfg (the declarative options) and only keep the C-extension building in it, but that's optional. Here's one of the PyPUG guides on the topic, but it doesn't cover C-exts: https://packaging.python.org/en/latest/guides/modernize-setup-py-project/.
• Modern tooling requires projects to have explicit [build-system] section in pyproject.toml for best results.
• Use pypa/build for making distribution packages; at least for making an sdist; I'll mention the wheels in the next point.
• I see that there are 3 wheels that are published, but it does not cover the actual user base, so most would be forced to compile the thing during the installation process (https://packaging.python.org/en/latest/guides/packaging-binary-extensions/#building-extensions-for-multiple-platforms). One is marked as manylinux2014 but there's no toolchain verifying that it's actually compliant (the auditwheel call + twine check --strict). It might also be needed to invoke auditwheel repair / delocate / delvewheel depending on the target. It's much easier to implement this nowadays, compared to the old times — it's now customary to use cibuildwheel (https://cibuildwheel.pypa.io) that does all the heavy lifting for you, which is a generic solution and is invocable both locally and in CI (you can optionally include running tests in that config and also make wheels for non-x86 arch easily). You might be able to cut the number of actual artifacts by using the abi3 tag in case the C-extensions are ABI-compatible (which they probably are, but I haven't checked).
• The dists are built in the same job as publishing, which is another thing I strongly discourage. Here's my PyPUG guide with a workflow example: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/. The jobs should be split, since giving the OIDC privilege to potentially poisoned (transitive) build deps has effects of extending the attack surface beyond PyPI. Here's one of the explanations Sigstore signing? hynek/build-and-inspect-python-package#105 (comment) (but you might find more elsewhere, I had to re-explain this a lot).
• https://docs.codecov.com/docs/contributing-to-the-cli has references to setup.py too, and it actually renders two commands in a single line so it's fully broken