The wheels and sdist to test from this release process. Will need to manually verify this still works on Windows and macOS before merging this PR. The artifact is fromhttps://github.com/pythongssapi/python-gssapi/pull/267/checks?check_run_id=3811298187 which essentially ran therelease.yml workflow just without the publishing steps.

artifact.zip

@aiudirog if you get a chance it would be great if you could validate some of the Windows wheels inartifact.zip. This PR changes the build process to usecibuildwheel and while I don't forsee any problems with the changes it would be nice to have that validated by someone who uses the library.

I've done a comparison on some of the.pyd files in the cibuildwheel wheels and ones from the latest release on PyPI and I couldn't find any linking differences which is a good sign. I was also able to install and import them just fine with Python 3.9 but that was a very basic sanity check.

I've manually tested themacOS wheels on an M1 Mac Mini and the wheels generated install and import correctly on both thearm64 andx86_64 Python installs I have there. Usingotool I can validate the dynamic links are the same with a manually built wheel from the sdist that currently occurs withpip install gssapi right now.

I feel confident the macOS wheels here will be fine going forward.

This looks great! Can we do an RC release (either 1.8.0rc1 or 1.7.1rc1, not sure where we are semver speaking) so the wheels get built this way and uploaded to PyPI but not set as the default for the public yet? Then I can run some tests on them exactly as they will be built.

That's a good idea, I'll probably settle on1.7.1rc1 as functionality there are no changes to the library, just the new wheel. There shouldn't be any breaking changes and hopefully the rc will prove that.