feature: add PyPy 3.9

[mayeut]

fixes #1032

[mattip]

Thanks!

[henryiii]

This looks like it is trying to test pypy on manylinux 2010, is that still supported? And I see:

cibuildwheel: python available on PATH doesn't match our installed instance. If you have modified PATH, ensure that you don't overwrite cibuildwheel's entry or insert python above it.

(And I don's see why this failed, 3.8 shouldn't have changed)

[mayeut]

This looks like it is trying to test pypy on manylinux 2010, is that still supported?

It's not supported anymore, the old versions are still installed on manylinux2010 but there's no PyPy 3.9.
Updated the test to skip PyPy 3.9 on manylinux2010.

[mattip]

I am sorry to report that PyPy3.7-v7.3.8 broke ABI compatibility with previous versions. Please pin PyPy3.7 to v7.3.7. I will be releasing a bug fix 😞. For more details here is the issue about broken ABI compatiblitiy, and here are the PyPy3.7-v7.3.8 changes.

[mattip]

The changes to update to pypy3.7-v7.3.8 were made in #1027. Should I make a separate PR to back those out or can it be done as part of this PR?

[henryiii]

Reverting in #1035. By the way, I'm just starting trying to make build's test suite pass on Windows, and I noticed that the bug in Path.resolve was fixed in CPython 3.8, but not PyPy 3.8: https://github.com/ofek/hatch/pull/136/files#diff-442ff120586375226c1759bc7fcfc162e7ca986db5a58f47ae45b45fb492c6f8. Also, winget is now installed by default on Windows (AFAICT), but there's no official PyPy package there (just a really weird winpython-pypy (3.7) / winpython-dot-pypy (3.8) that's 500 MB and not clearly versioned). Given that's Windows official (vs. third party tools like chocolaty) CLI app installer, having PyPy there would be great!

[mattip]

the bug in Path.resolve was fixed in CPython 3.8, but not PyPy 3.8

I am not sure I follow. Which bug and how was it resolved? Is this part of the (lack of) good support for symlinks on PyPy windows?

[mattip]

About winget, I commented on an open issue there. We have done 90% of the work to port the CPython installer to PyPy, which means there is only 80% left 😄. The process is layered on top of PyPy, so does not involve much actual PyPy-specific knowledge, rather the work needs someone who can deal with the minutia of windows to get it over the finish line.

[henryiii]

I think it was this one: https://bugs.python.org/issue38671 and it was backported to 3.8 and 3.9 from 3.10, so it might based on the stdlib patch version.

[mattip]

if it was part of the stdlib, it should be part of PyPy. Can we move the discussion of path.resolve() somewhere where we can discuss this more deeply, preferably with a test that CPython3.8 passes but PyPy3.8 fails? I don't understand what is failing and how CPython fixed it.

[henryiii]

I think it's this test: python/cpython#26184.

[henryiii]

(Back on topic) Unless manylinux releases a mixed pypy version image, I think we can't blend manylinux images based on PyPy versions. (A user can via overrides, actually, but not our defaults.)

[mayeut]

The plan in pypa/manylinux#1289 is to revert PyPy 3.7 to 7.3.7 and go on with 7.3.8 for PyPy 3.8 & 3.9

[mayeut]

There are now 3 commits here:

• revert PyPy 3.7 to 7.3.7
• prevent automatic updates of PyPy 3.7 to 7.3.8 (to be reverted, probably not in this PR, once 7.3.9 lands)
• Add PyPy 3.9 7.3.8