Add support for Python 3.11. #253
Conversation
There was a problem hiding this comment.
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.
|
@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 have no idea how to debug these problem. |
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 $ 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
... |
|
@jamadden Thank you for looking into this problem. Would you like to create in issue in the |
|
It was recorded in nedbat/coveragepy#1294 and fixed a few days ago, just waiting for a release. |
|
Okay let's await the next coverage release then. |
|
Wow, the release was just yesterday. Let's se what happens when re-running the tests. |
|
What a pity: using |
|
The behavior for ExtensionClass did not change either using |
|
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 |
Remove some coverage installs where they do not seem to be needed.
|
@jamadden Thank you for sharing your expertise. I changed to |
|
I added code to prevent pushing wheels of future Python versions to PyPI, see 5e81b38 and zopefoundation/meta#132 |
But it was before, I do not understand why.
|
Okay preventing publishing wheels was not so easy but now it should work as expected. |
|
Thank you for reviewing this PR. 😃 |
No description provided.