Build abi3 wheels for Python 3.11+

[effigies]

Some initial playing around with getting Stable ABI builds to work. The benefit would be that if you publish wheels with cp3N-abi3, then any Python versions >= 3.N can install the same wheel without your having to do anything apart from fix compatibilities with the new Python versions.

Looking at the symbols indexed_gzip uses, PyObject_GetBuffer was only added to the stable ABI in 3.11, so that sets a lower bound on ABI3 wheels.

To get it to compile, I also needed to depend on cython/cython#5871. Leaving as draft for now, since this seems like a Bad Idea to code a dependency on in your pyproject.toml. abi3audit also complains about the use of Py_DECREF; I've removed them here, but we'd need to wait on cython/cython#6063 for it to be entirely clean.

I tried to modify your setup.py defensively, so that it would only attempt to build an ABI3 build if both Python and Cython were new enough. I have tested, and I'm able to install a wheel built with Python 3.11 on Python 3.12.

[effigies]

Looks like this isn't going to play nicely with your tests until Cython's limited API fixes are released.

[pauldmccarthy]

@effigies No worries, thanks for looking into this.

[pauldmccarthy]

cibuildwheel appears to be smart enough to skip redundant builds 😁

Found previously built wheel indexed_gzip-0.1.dev1+gc5707a1b2-cp311-abi3-manylinux2014_x86_64.manylinux_2_17_x86_64.manylinux_2_28_x86_64.whl, that's compatible with cp312-manylinux_x86_64. Skipping build step...

[da-woods]

abi3audit also complains about the use of Py_DECREF;

FWIW this was mostly a false positive from abi3audit. See pypa/abi3audit#85.

It was always intended that Py_DECREF would be usable from the limited API, but it isn't part of the stable ABI because it's a macro. So this part of the PR probably wasn't necessary (but equally doesn't do any harm).

[pauldmccarthy]

@da-woods thanks - if I understand correctly, PY_DECREF (and similar) calls will be inlined into the calling code, so once our code is complied they're baked in, and it wouldn't matter if their definitions change in future Python version?

But changing to Py_DecRef sounds like a nicer/safer option to me anyway 😁

[da-woods]

Yes - they should be inlined, and nobody's going to change anything that breaks the inlines definition.

The main advantage of Py_IncRef/Py_DecRef is that it'll work better with immortal objects with Limited API versions <3.12. Nothing will break, but immortal objects won't work as well.