[Bot] Update dependencies

[github-actions]

Update the versions of our dependencies.

PR generated by "Update dependencies" workflow.

[henryiii]

Wow, looks like we have 3.8 universal finally! That would be great, as the built in AS Python is 3.8.

[henryiii]

Yep, it's official: https://pythoninsider.blogspot.com/2021/05/python-3810-395-and-3100b1-are-now.html

So a follow up would be to expand this to 3.8 and make the check in macOS.py check for 3.8+ instead of just string comparing 39. (Also needed for 3.10 soonish). Could make it an exclusion from {"36", "37"}, actually.

[mayeut]

Compared to the 3.9 installer, it's marked experimental on the release page and doesn't mention 10.9 as the minimal macOS on x86_64, only 11.0 BigSur. If I'm reading the logs from azure macOS correctly, the tests unfortunately seem to confirm 11.0 as the minimal macOS version.

[joerick]

I see a pip resolver error on Azure, but I see something similar on the CircleCI mac tests- Symbol not found: ____chkstk_darwin

Traceback (most recent call last):
File "/Users/distiller/project/cibuildwheel/resources/install_certifi.py", line 11, in
import ssl
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/ssl.py", line 98, in
import _ssl # if we can't import it, let the error propagate
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/lib-dynload/_ssl.cpython-38-darwin.so, 2): Symbol not found: ____chkstk_darwin
Referenced from: /Library/Frameworks/Python.framework/Versions/3.8/lib/libcrypto.1.1.dylib (which was built for Mac OS X 11.0)
Expected in: /usr/lib/libSystem.B.dylib
in /Library/Frameworks/Python.framework/Versions/3.8/lib/libcrypto.1.1.dylib
Error: Command ['sudo', '/Library/Frameworks/Python.framework/Versions/3.8/bin/python3', '/Users/distiller/project/cibuildwheel/resources/install_certifi.py'] failed with code 1. None

Looks like it was built without a MACOSX_DEPLOYMENT_TARGET. Oh well. I guess we can't use this version without macos-11 runners. Can we exclude it from the auto-update script?

[henryiii]

I guess auditwheel 4 must be out...

[mayeut]

I guess auditwheel 4 must be out...

Indeed it is:

• Release 4.0.0 auditwheel#304
• Bump auditwheel from 3.3.1 to 4.0.0 in /docker/build_scripts manylinux#1082
• Bump auditwheel from 3.3.1 to 4.0.0 in /docker/build_scripts manylinux#1080

[joerick]

Did the bot-generated PRs never run Github Actions? I see now that it's a policy. The workaround is to set a Personal Access Token on the bot. I can set this up unless there's another workaround?

[mayeut]

Did the bot-generated PRs never run Github Actions? I see now that it's a policy. The workaround is to set a Personal Access Token on the bot. I can set this up unless there's another workaround?

I did not dig too much around this but I guess a Personal Access Token is required when calling the peter-evans/create-pull-request action and that there's no workaround as of yet.

[joerick]

I found there are a few workarounds here. Actually a PAT has unscoped access to my entire Github account. So not a great solution. I'm thinking that a bot account might be the best approach.

[henryiii]

Would switching to the gh CLI help?

[joerick]

Would switching to the gh CLI help?

No, the problem is using the $GITHUB_TOKEN to push. I'm looking into some options now, actually perhaps a custom Github app will do the trick, because I note that pre-commit.ci gets GHA runs.

[joerick]

I've resolved the GHA not testing automated PRs thing - for reference, I followed the instructions here.

• I created a Github App, and gave it permissions on this repo.
• I added secrets for the app's ID and private key to this repo.
• The workflow gets an API token from that app, and the PR is created using that token. The code changes for this are in 024334a.

Of course, I didn't resist the urge to give it a cute robot icon too :)

[mayeut]

Nice one & good to know !

It now requires #633 for tests to pass I guess ?

[joerick]

Yes, I think that #633 is needed. But also I see that the pypy patch is failing, which implies that #629 will also be needed.

[mayeut]

But also I see that the pypy patch is failing, which implies that #629 will also be needed.

Not sure we need the full #629
The ABI does not change between 7.3.3 & 7.3.4 so I think we can live with just updating the linux image (& removing patching on linux) while waiting for 7.3.5 & the full PyPy upgrade in #629 ?

Edit: Tests are passing in #633 even with PyPy patching failing on PyPy 3.7 (they probably shouldn't)

[joerick]

Ah, the new pypy/manylinux image still contains 7.3.3?

joerick@joerick4 ~> docker run -it pypywheels/manylinux2010-pypy_x86_64:2021-05-08-8650a6d bash
[root@9ddc11d715fe /]# ls -l /opt/pypy
total 20
drwxr-xr-x 9 root root 4096 Oct 18  2019 pypy2.7-7.2.0
drwxr-xr-x 8 root root 4096 Apr  4 10:55 pypy2.7-7.3.4
drwxr-xr-x 9 root root 4096 Oct 18  2019 pypy3.6-7.2.0
drwxr-xr-x 8 root root 4096 Nov 18 10:17 pypy3.6-7.3.3
drwxr-xr-x 8 root root 4096 Apr  4 11:53 pypy3.7-7.3.4
[root@9ddc11d715fe /]# ls -l /opt/python/
total 0
lrwxrwxrwx 1 root root 31 May  5 21:32 cp310-cp310 -> /opt/_internal/cpython-3.10.0b1
lrwxrwxrwx 1 root root 29 May  5 21:32 cp36-cp36m -> /opt/_internal/cpython-3.6.13
lrwxrwxrwx 1 root root 29 May  5 21:32 cp37-cp37m -> /opt/_internal/cpython-3.7.10
lrwxrwxrwx 1 root root 29 May  5 21:31 cp38-cp38 -> /opt/_internal/cpython-3.8.10
lrwxrwxrwx 1 root root 28 May  5 21:32 cp39-cp39 -> /opt/_internal/cpython-3.9.5
lrwxrwxrwx 1 root root 23 May  8 15:18 pp27-pypy_41 -> /opt/pypy/pypy2.7-7.2.0
lrwxrwxrwx 1 root root 23 May  8 15:17 pp27-pypy_73 -> /opt/pypy/pypy2.7-7.3.4
lrwxrwxrwx 1 root root 23 May  8 15:18 pp36-pypy36_pp73 -> /opt/pypy/pypy3.6-7.3.3
lrwxrwxrwx 1 root root 23 May  8 15:17 pp36-pypy3_72 -> /opt/pypy/pypy3.6-7.2.0
lrwxrwxrwx 1 root root 23 May  8 15:18 pp37-pypy37_pp73 -> /opt/pypy/pypy3.7-7.3.4
[root@9ddc11d715fe python]# 

Currently we use:

  { identifier = "pp36-manylinux_x86_64", version = "3.6", path_str = "/opt/python/pp36-pypy36_pp73" },
  { identifier = "pp37-manylinux_x86_64", version = "3.7", path_str = "/opt/python/pp37-pypy37_pp73" },

So there's both 7.3.3 and 7.3.4 on this new image. But... ahhh, damn, there's no pypy3.7-7.3.3 on this image. So we're kinda forced into the 7.3.4 upgrade, right? But the good news is that we don't need to wait for 7.3.5 because we dropped 2.7 anyway :)

[mayeut]

But... ahhh, damn, there's no pypy3.7-7.3.3 on this image. So we're kinda forced into that upgrade, right?

Yeah, sooner or later. There's no reason for the PyPy image to keep 7.3.3 (although PyPy3.6 is still 7.3.3 and not 7.3.4, #629 drops PyPy 3.6 altogether).

The only OS that requires waiting for 7.3.5 is Windows I guess which shall not use 7.3.4 to build wheels: #629 (comment)

[henryiii]

The request was to leave 3.6 at 7.3.3 (since there is no 3.6 for 7.3.4). The only thing we cannot yet upgrade is PyPy 7.3.4 on Windows, which produces incorrect wheel tags. But no reason to avoid the Linux PyPy upgrade (or maybe even macOS). Since PyPy has dropped 3.6, we could do the same.

[joerick]

Ah, yep, you guys are right, I misread that. We do have to wait for 7.3.5 for Windows. Thanks for the correction!

But no reason to avoid the Linux PyPy upgrade (or maybe even macOS). Since PyPy has dropped 3.6, we could do the same.

True, true. Okay, let's do that to get things green. We probably won't be releasing anything for a few weeks, by which time 7.3.5 might be out anyway.

[joerick]

If anyone else was confused by the above - the dependency update went in in #633, so this PR became redundant - zero changes.