hmm ... looks like pypi is no longer available on bitbucket to download...

$env:PYTMP = "${env:TMP}\py"; if (!(Test-Path "$env:PYTMP")) { New-Item -ItemType directory -Path "$env:PYTMP" | Out-Null; } if ("${env:PYTHON_ID}" -eq "pypy") { if (!(Test-Path "${env:PYTMP}\pypy2-v7.3.1-win32.zip")) { (New-Object Net.WebClient).DownloadFile('https://bitbucket.org/pypy/pypy/downloads/pypy2.7-v7.3.1-win32.zip', "${env:PYTMP}\pypy2-v7.3.1-win32.zip"); } 7z x -y "${env:PYTMP}\pypy2-v7.3.1-win32.zip" -oC:\ | Out-Null; } elseif (-not(Test-Path($env:PYTHON))) { & appveyor\install.ps1; }
Exception calling "DownloadFile" with "2" argument(s): "The remote server returned an error: (404) Not Found."
At line:1 char:221
+ ... 32.zip")) { (New-Object Net.WebClient).DownloadFile('https://bitbucke ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WebException
 
7z : 
At line:1 char:373
+ ... 32.zip"); } 7z x -y "${env:PYTMP}\pypy2-v7.3.1-win32.zip" -oC:\ | Out ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
ERROR: The system cannot find the file specified.
C:\Users\appveyor\AppData\Local\Temp\1\py\pypy2-v7.3.1-win32.zip
System ERROR:
The system cannot find the file specified.
Command executed with exception: 
System ERROR:
The system cannot find the file specified.

It looks like something changed in Python 3.9.7 around threading and interpreter shutdown that's causing a test to fail. (The same test passes in 3.9.7.) Not the fault of this PR, of course.

hmm .. I'm getting a crash in 3.8.12 locally:

! /Users/csalch/virtualenvs/gevent-test/bin/python -u -mgevent.tests.test__doctests [code TIMEOUT] [took 100.0s]
Reaping 0 jobs

Longest-running tests:
100.0 seconds: /Users/csalch/virtualenvs/gevent-test/bin/python -u -mgevent.tests.test__doctests
 30.6 seconds: /Users/csalch/virtualenvs/gevent-test/bin/python -u -m unittest gevent.tests.test__os gevent.tests.test__pool gevent.tests.test__queue gevent.tests.test__real_greenlet gevent.tests.test__refcount_core gevent.tests.test__resolver_dnspython
 28.7 seconds: /Users/csalch/virtualenvs/gevent-test/bin/python -u -W ignore -m gevent.testing.monkey_test test_subprocess.py
 27.4 seconds: /Users/csalch/virtualenvs/gevent-test/bin/python -u -W ignore -m gevent.testing.monkey_test test_ssl.py
 23.4 seconds: /Users/csalch/virtualenvs/gevent-test/bin/python -u -m unittest gevent.tests.test__events gevent.tests.test__example_echoserver gevent.tests.test__example_udp_server gevent.tests.test__example_wsgiserver_ssl gevent.tests.test__examples gevent.tests.test__exc_info

1/68 tests failed in 01:52

1/68 unexpected failures
 - /Users/csalch/virtualenvs/gevent-test/bin/python -u -mgevent.tests.test__doctests

Ran 3742 tests (skipped=723) in 68 files in 01:52

An ancient (2006) Python bug involving threads and shutdown was fixed for 3.9 and eventually for 3.10. But the fix is incompatible with gevent, which also has to manage threads and shutdown carefully. It'll take some looking to figure out a fix.

I'm getting a crash in 3.8.12 locally:

First, thanks for being willing to run them! I've seen test__doctests timeout before and have never been able to adequately explain it. It happens most often using tox, so its somehow environment or path dependent. (These things should be fixed, but I've not spent much time on it.)

A couple of things to try:

1. If your current working directory is not the root of a gevent source tree (e.g., beside setup.py), try changing to there and running the python -m gevent.tests again.
2. You can also try just running python -m gevent.tests.test__doctests. If you're not in the gevent root, these might fail (for weird reasons), but they probably won't hang. If you're in the gevent root, I'd expect them to work fine.

If the first one works, or you get interesting output from the second, please let us know.

@jamadden my team is using gevent with Python 3.9 on x86 machines and things appear to be working fine. Is there some issue that we are not noticing?

It has to do with the interactions between gevent and multiple native threads. The manifestation in the test suite is that the test that monkey-patches from a non-main thread hangs on 3.9.8 and above when the interpreter tries to exit; you have to kill it with ctrl-C.

$ python -u -mgevent.tests.test__threading_monkey_in_thread
.
----------------------------------------------------------------------
Ran 1 test in 0.236s

OK
^CException ignored in: <module 'threading' from '//3.9/lib/python3.9/threading.py'>
Traceback (most recent call last):
  File "//3.9/lib/python3.9/threading.py", line 1470, in _shutdown
    lock.acquire()
KeyboardInterrupt:

In the past, gevent has had to special-case some things around this, in part to workaround the bug that just got fixed in CPython. But just disabling that workaround doesn't fix the test.

On running tests: Running tox -e py9 on gevent.master and csalch/patch-m1-deps (deleting the .tox cache dir in between) I get same results on both branches.

2/68 tests failed in 02:07

2/68 unexpected failures
 - /.../contributing/gevent/.tox/py39/bin/python -u -mgevent.tests.test__doctests
 - /.../gevent/.tox/py39/bin/python -u -mgevent.tests.test__threading_monkey_in_thread

Ran 4056 tests (skipped=837) in 68 files in 02:07
ERROR: InvocationError for command /.../gevent/.tox/py39/bin/python -m gevent.tests (exited with code 2)

This is on an M1 running Monterey.

Should I expect different? Should 837 test have been skipped?

Should this patch fix the /usr/local intel vs /opt/local arm64 issue?

If I install via python3 -m pip install -e <path-to-csalch/patch-m1-deps> I still get the same error mentioned in #1721, even though the tests run (as above).

Should this patch fix the /usr/local intel vs /opt/local arm64 issue?

No, this patch has nothing to do with CFFI. gevent has no control over CFFI. However, since you were able to build gevent and run the tests, presumably the updated CFFI that was installed solves the problem.

Thanks everyone!

I'll deal with the 3.9.8 issue separately.

Should this patch fix the /usr/local intel vs /opt/local arm64 issue?

No, this patch has nothing to do with CFFI.

yes, but the CFFI issue linked to this one.

However, since you were able to build gevent and run the tests, presumably the updated CFFI that was installed solves the problem.

See my details on the other issue. I hope they’re useful.

They're not particularly helpful, no. They're out of context, you don't specify any details around when you get that error or with what CFFI version. But since above you said you built gevent and ran the tests, I can only assume that the newer CFFI version fixed it.