Add support for Python 3.11.

[icemac]

No description provided.

[jamadden]

As long as manylinux docker images never include pre-release versions of CPython, this mostly LGTM. (We don't want to take a chance on publishing a binary wheel compiled against a CPython whose ABI isn't stable yet.)

I am slightly concerned that appveyor.yml won't get updated when 3.11 goes final and we publish the next release. It would be nice if it could gracefully handle missing releases or something.

[icemac]

@jamadden I share your concerns. I currently see no way to address them and keep the chance to test against non-final versions to see upcoming problems early.

Currently we have a Segmentation Fault on Unbuntu for Python 3.11.0a4, see https://github.com/zopefoundation/zope.interface/runs/4922368009?check_suite_focus=true
I saw a similar Segfault in the tests of ExtensionClass pointing to zope.interface: https://github.com/zopefoundation/ExtensionClass/runs/4912932639?check_suite_focus=true 3.11.0a3 did not have this Segfault.

I have no idea how to debug these problem.

[jamadden]

Currently we have a Segmentation Fault on Unbuntu for Python 3.11.0a4

That's an intermittent failure (at this writing, the PR run passed for 3.11, but failed for the push; I'll try re-running the push). I see the same thing in a local docker container of Ubuntu 20.04 using the deadsnakes build of 3.11a4 (roughly 50% run, and 50% crash).

Running under gdb seems to point the finger to an error in coverage, not this package:

$ gdb /usr/bin/python3.11
...
(gdb) run -m coverage run -m unittest discover src
Starting program: /usr/bin/python3.11 -m coverage run -m unittest discover src
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
CTracer_handle_return (frame=0x7f54d570ea30, self=0x7f54d5a85b30) at coverage/ctracer/tracer.c:698
698	coverage/ctracer/tracer.c: No such file or directory.
(gdb) bt
#0  CTracer_handle_return (frame=0x7f54d570ea30, self=0x7f54d5a85b30) at coverage/ctracer/tracer.c:698
#1  CTracer_trace (self=0x7f54d5a85b30, frame=0x7f54d570ea30, what=3, arg_unused=<optimized out>) at coverage/ctracer/tracer.c:784
...

[icemac]

@jamadden Thank you for looking into this problem. Would you like to create in issue in the coverage project?

[jamadden]

It was recorded in nedbat/coveragepy#1294 and fixed a few days ago, just waiting for a release.

[icemac]

Okay let's await the next coverage release then.

[icemac]

Wow, the release was just yesterday. Let's se what happens when re-running the tests.

[icemac]

What a pity: using coverage 6.3 did not help, see https://github.com/zopefoundation/zope.interface/runs/4948035836?check_suite_focus=true

[icemac]

The behavior for ExtensionClass did not change either using coverage 6.3. 😢

[jamadden]

Unfortunately, we're installing the pre-built binary wheel for coverage, and I believe those are still built against Python 3.11a2. That's binary incompatible with 3.11a4. (This is why you don't publish wheels built on pre-releases!)

I can still reproduce the crashes easily locally using the pre-built coverage 6.3 wheels. But if I install coverage with --no-binary and build it from source, I don't get crashes.

[icemac]

@jamadden Thank you for sharing your expertise. I changed to --no-binary and removed installing coverage at some places where it does not seem to be necessary. Let's see how it goes.

[icemac]

I added code to prevent pushing wheels of future Python versions to PyPI, see 5e81b38 and zopefoundation/meta#132

[icemac]

Okay preventing publishing wheels was not so easy but now it should work as expected.

[icemac]

Thank you for reviewing this PR. 😃