Specify the PyPy version to target in tox

[kurtmckee]

This helps ensure that PyPy 3.10 is actually getting tested locally.

[masklinn]

Could I know what the problem is? Because AFAIK pypy 3.10 is not an actual pypy version just capabilities for that specific build, the actual pypy version could be anywhere from 7.3.12 to 7.3.17, and at the end of the day it shouldn't matter if the user is running pypy3.9 (7.3.10~7.3.16) or an eventual pypy3.11 when that happens as the lib should be compatible with them all?

Which is why I removed that from the tox target (alongside the graal versions, though they are more meaningful as they're the actual version of graalpy and i don't think graal is multipy).

[kurtmckee]

Without a version specifier, "pypy" matches any version that's installed on the developer PC, regardless of whether it's a supported language version.

For example, I have PyPy 3.7 available on my machine, and if that's the only PyPy version available, running tox run -e pypy results in a SyntaxError in ua-parser-builtins/hatch_build.py due to Python 3.7-incompatible with syntax.

Specifying pypy310 prevents PyPy 3.7 from matching.

In short, it's just as important to specify the PyPy language version (like pypy310) as it is the CPython version, and that's what this PR targets.

Addendum: pypy310 matches the PyPy language version, not the application version. This is why it's important to specify.

Also, I only added pypy310 instead of pypy3{9, 10} because PyPy 3.9 is no longer supported.

[masklinn]

Without a version specifier, "pypy" matches any version that's installed on the developer PC, regardless of whether it's a supported language version.

Yes, that's the point.

For example, I have PyPy 3.7 available on my machine, and if that's the only PyPy version available, running tox run -e pypy results in a SyntaxError in ua-parser-builtins/hatch_build.py due to Python 3.7-incompatible with syntax.

Specifying pypy310 prevents PyPy 3.7 from matching.

Technically sure but practically you have a pypy that's two years out of date so does it actually have any relevance? You're either getting an error because you don't have a compatible pypy, or you're getting an error because you don't have a compatible pypy.

In short, it's just as important to specify the PyPy language version (like pypy310) as it is the CPython version

It's not though.

Also, I only added pypy310 instead of pypy3{9, 10} because PyPy 3.9 is no longer supported.

So is pypy 3.7.

Not that I would add multiple versions of either pypy or graal, at least not until #235 is attempted and demonstrates that it can lead them to run the test suite in a reasonable amount of time, reliably.