Pin to pypy-3.9-v7.3.13 in CI

[ecerulm]

CI seems to be continuosly failing on the test-pypy under pypy3.9.

Currently pypy3.9 is mapped to pypy3.9-v7.3.15 and I believe this particular version of pypy is causing the "coverage" take way longer.

In this PR I'm pinning the version to pypy3.9-v7.3.13, this I think makes the test-pypy to complete in under 8 minutes instead of the current +30 minutes which causes the CI job to be cancelled.

Closes #3305

[ecerulm]

You can see that now the test-pypy for pypy3.9 finishes in 9 minutes,

You can see that in many of the other PR by other authors the test-pypy for pypy-3.9 takes more that 30 minutes:

• encode stringIO bodies to utf-8 #3296
• Emit insecure proxy event when using unverified proxies #3070
• Distinguish between truncated and excess content in response #3273

[sethmlarson]

@ecerulm Interesting, this makes me wonder what changed between 7.3.13 and 7.3.15. If we figure that out we should report it to PyPy in case its a regression.

[sethmlarson]

@ecerulm Can you create an issue on the https://github.com/pypy/pypy repository pointing back to this finding? Maybe they'll have some ideas, but if we have time we should poke around ourselves too.

Going to merge this to help others' CI.

[ecerulm]

@ecerulm Interesting, this makes me wonder what changed between 7.3.13 and 7.3.15. If we figure that out we should report it to PyPy in case its a regression.

Sure, I was going to do that, but I suspect is more a "coverage" thing. pypy is different from cPython, there are thing that in cPython are implemented in C and therefore "coverage" does not look into them. But in pypy some of those things are implemented in pure python and therefore coverage can get "overwhelmed" by tracking those. I suspect that there is something between pypy-3.9-v7.3.13 and pypy-3.90-v7.3.15 that makes coverage==7.4.0 go nuts.

I'll try to verify this suspicion and report it back to coverage and/or pypy

[pquentin]

Great find, thanks! It will be interesting to see what is culprit. The good news is that the PyPy maintainers and the coverage.py maintainer have some sort of superhuman abilities and always fix our bugs quickly.

[ecerulm]

I'll setup another PR with pypy-3.9-v7.3.15 and remove the -m coverage run --parallel-mode to see if that is the case.
Unfortunately, I can't really test with pypy-3.9-v7.3.15 in my laptop because pyenv does not support that version yet.

[ecerulm]

Great find, thanks! It will be interesting to see what is culprit. The good news is that the PyPy maintainers and the coverage.py maintainer have some sort of superhuman abilities and always fix our bugs quickly.

Then maybe I will report this straight away.

[pquentin]

Well, it is still useful to report if coverage is needed, and what PyPy patch version causes the issue.

[pquentin]

There's a coverage issue for PyPy 7.3.15, but only on Windows: nedbat/coveragepy#1737

[ecerulm]

nedbat/coveragepy#1738

[ecerulm]

I run a test with pypy3.9-7.3.15 without -m coverage run --parallel-mode and it progresses farther but still takes more that 30 minutes https://github.com/urllib3/urllib3/actions/runs/7628197451/job/20778656524?pr=3309

So I guess it's not really coverage fault. I'll write a ticket on pypy repo

[ecerulm]

pypy/pypy#4877

[mattip]

Is there a single test or type of test that is slower, or is it an across-the-board slowdown?
Is there a way to run the test suite with pytest's --duration to see what is going on? I don't use nox, so I would need some help how to manipulate test running.

[ecerulm]

Is there a single test or type of test that is slower, or is it an across-the-board slowdown?
It's across-the-board slowdown,

Also it only happens in pypy3.9-7.3.15 on Ubuntu 22.03.4 LTS. I tied on pypy3.9-7.3.15 on macOS Sonoma 14.3 and there the test run quite fast.

[ecerulm]

I opened #3323 to keep track of the issue with pypy3.9-7.3.14 and pypy3.9-7.3.15.

Further discussion should happen there.