Closed jaraco closed 7 months ago
Between that build and the prior run, the PyPy version changed from 7.3.11 (Python 3.9.16) to 7.3.12 (Python 3.9.17).
Testing locally, I have pypy 7.3.10-alpha, and tests pass.
Looks like maybe the reason I have an old pypy is because I built/installed it from source to support macOS ARM. It does appear that 7.3.12 is available on homebrew now.
After realizing that brew install pypy
installs an old and deprecated version of Python (yeah, I know pypy still supports Python 2.7; still, I expect a naked "pypy" to install the most modern stable version available), I installed pypy3 and that gave me pypy 7.3.12 (Python 3.10.12). In that environment, I'm unable to replicate the failure.
I am, however, able to replicate the issue using pypy 3.9.
Well, I did replicate it once, but the failure went away.
WTH?
Note that while I did rebuild the environment above, it wasn't the rebuilding the environment that allowed the tests to start passing. After the original error occurred, I set out to use pdb to triage, and even then, the replicated failure did not occur:
I've repeated that command using watch
(watch tox -e pypy3.9 -- -p no:cov -p no:perf -k egg
) and it's just not failing. It seems it's not an intermittent issue but more of an "initial state" issue. I removed and reinstalled pypy3.9, then ran the command an it failed. Then I ran the command again and it passed.
In an attempt to understand better the differences between a fresh failing run and a passing run, I ran the following:
importlib_metadata main @ brew install pypy3.9
...
importlib_metadata main @ mtree -c -K sha256digest -p /opt/homebrew > before.mtree
importlib_metadata main @ tox -e pypy3.9 -- -p no:cov -p no:perf -k egg > out.txt
importlib_metadata main @ mtree -p /opt/homebrew < before.mtree
Here's the output from that last command:
Curiously (and maybe unrelated), there seems to be a glitch in path handling that's causing the duplicate path to be created in /opt/homebrew/Cellar/pypy3.9/7.3.12/libexec/lib/pypy3.9/opt/homebrew/Cellar/pypy3.9/7.3.12/libexec/lib/pypy3.9/_testmultiphase.o
.
That fact may be implicated in the failure, which I can now repeat without reinstalling pypy, but instead removing _testmultiphase prior to running the tests:
importlib_metadata main @ rm /opt/homebrew/Cellar/pypy3.9/7.3.12/libexec/lib/pypy3.9/_testmultiphase.pypy39-pp73-darwin.so
Based on timing and other common factors, I suspect the issue is related to pypy/pypy#3953.
I do see both test_files_egg_info
and test_packages_distributions_on_eggs
failing the exactly same way with importlib_metadata 6.9.0
on OpenIndiana when tested with Python 3.9.16.
I do see both
test_files_egg_info
andtest_packages_distributions_on_eggs
failing the exactly same way withimportlib_metadata 6.9.0
on OpenIndiana when tested with Python 3.9.16.
When you say Python 3.9.16, do you mean CPython or PyPy? If the former, that's interesting and surprising as this issue was previously isolated to PyPy... and tests have been passing reliably on CPython across popular platforms throughout. Do you have a way to replicate it?
I have re-enabled the PyPy tests in CI, since upstream skeleton has bumped from 3.9 to 3.10, bypassing the underlying issue.
Moreover, now that I have pypy 7.3.13 (3.9.18), I'm no longer able to replicate the issue locally, even after deleting _testmultiphase.pypy39-pp73-darwin.so
. Confirming the upstream fix for pypy/pypy#3953.
I do see both
test_files_egg_info
andtest_packages_distributions_on_eggs
failing the exactly same way withimportlib_metadata 6.9.0
on OpenIndiana when tested with Python 3.9.16.When you say Python 3.9.16, do you mean CPython or PyPy? If the former, that's interesting and surprising as this issue was previously isolated to PyPy... and tests have been passing reliably on CPython across popular platforms throughout. Do you have a way to replicate it?
When I say Python 3.9.16 I mean CPython. And yes, it looks like it is reproducible reliably. When I played with importlib_metadata 6.9.0
yesterday both tests failed all the time, reliably and reproducible. I ran testing several times, definitely more than 5, maybe even more than 10, I didn't count them...
Moreover, now that I have pypy 7.3.13 (3.9.18), I'm no longer able to replicate the issue locally, even after deleting
_testmultiphase.pypy39-pp73-darwin.so
. Confirming the upstream fix for pypy/pypy#3953.
I do not have CPython > 3.9.16 handy so I cannot confirm.
Although the issue may be similar, I think it's better to track the new failure in a separate issue Thanks for filing #479.
Around two weeks ago, in this build, tests started failing on PyPy, implicating f5a56179ad9093f7b9a29742ae3854713cce35f9. Is it the case that
pypy3.9
needs-dev
?