-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests failing on master (macOS Monterey / py 3.7) #12615
Comments
NB: initial report included a mypyc build failure, which turned out to be caused by using python 3.7.8 built via pyenv prior to the upgrade to Monterey. Using a freshly build 3.7.13 solved that. The flakiness persists however... |
For what it's worth, I am seeing the exact same thing on Python 3.10, also on Mac Monterey (12.3.1), not sure if it's relevant but I have the Apple M1 cpu, and so I compile my Pythons for arm64. |
I suspect that this is caused by some shared file system state, and only reproduces when running tests in parallel. All the tests passed when I ran them sequentially (on macOS). Also CI has been reliable, and it doesn't use much/any parallelism. |
I saw this on Linux too, on Python 3.10.4. Confirm that things work reliably and consistently with |
|
I got this suite to pass, reliably, in two ways -- neither of them very pretty. One is to just pass Some completely informal timings: For reference, the current state of master branch does them rather more quickly -- but requires a bunch of attempts to pass all cases, in particular with more workers:
I'm not sure if this actually affects a lot of people; it might be just something particular to my environment (although I did see it on both Mac and Linux recently). But if anyone thinks that the added running time is worth it, here's what I've done: sequential: erikkemperman@b68aac5 filelock: erikkemperman@3648f5c |
One thing I was hoping would work, but seems not to, is passing I think a lock on the tests is unfortunately the only way forward then. |
By the way, the pip issue for this is pypa/pip#2361 |
Yes, I tried setting —cache-dir as well, and —no-cache, but no luck. |
@erikkemperman well if you want to make a PR I'd be happy to review it, I think the tests running a bit slower rather than failing is an acceptable tradeoff. |
Excellent @erikkemperman . |
Ah my apologies for misspelling the name! |
My pleasure to take part in great doing! |
Fixes #12615. As discussed in the linked issue, this PR would put a filesystem-based lock around the pip install steps of the suite of PEP561 testcases, to address race conditions. It introduces a test-dependency on tox-dev/py-filelock. I used 3.0.0 as a lower bound, simply because that's what the tox version mentioned in tox.ini specifies as its lower bound. However from the release history it seems that Python 3.6 support was dropped in 3.4.2, hence the second line in the requirements. I ended up just adding the location of the lock file to .gitignore -- I guess it would be possible to try and remove it after the suite has run, e.g. with atexit.register, but I didn't want to make this complicated.
Bug Report
Tests are failing for the master branch on my macOS laptop.
A few tests in
PEP561Suite
are flaky for reasons I don't quite understand.To Reproduce
Expected Behavior
Tests pass.
Actual Behavior
There's usually exactly one failure per run. On some rare occasions I've seen more than one failure, or no failures.
Here are some sample failures:
Your Environment
mypy commit
f501cf649d7976077a7196e3548d773d67340a8c
Python 3.7.13
macOS Monterey 12.3.1
x86_64
The text was updated successfully, but these errors were encountered: