chore: bump macOS PyPy to 7.3.4, and drop PyPy 3.6

[henryiii]

Rebased (and closes #629).

• chore: update PyPy to 7.3.4 except on Windows
• chore: bump dependencies

[henryiii]

Looks like things are passing. Would like 1-2 sign-offs, as this does drop PyPy 3.6.

[joerick]

Looks good to me! Let's try and get a @YannickJadoul review before merging, if possible.

[YannickJadoul]

I don't get where this is coming from.
Why are we doing this, instead of just going with #629 that I've been preparing? That should be ready (especially, since the manylinux image was merged recently).

Also, I was actually still waiting with that, because PyPy is almost releasing 7.3.5, with a (reasonably urgent?) bugfix. They're already at rc2, so I'm expecting a final release soon.

[YannickJadoul]

Why are we doing this, instead of just going with #629 that I've been preparing? That should be ready (especially, since the manylinux image was merged recently).

That seems a lot better for tracability. And I just checked, no one poked me there to rebase or merge anything.

Also, I was actually still waiting with that, because PyPy is almost releasing 7.3.5, with a (reasonably urgent?) bugfix. They're already at rc2, so I'm expecting a final release soon.

See also #629 (comment)

[henryiii]

Why are we doing this, instead of just going with #629 that I've been preparing?

This is #629; you'll see you are a coauthor to this. I felt a little weird force-pushing such a major change to your branch, but it is your work and is attributed to you, if you are worried about that, it's just a rebase + rerun of the update script. I can force-push there if you want, and close this. Really all that's left is removing PyPy3.6 (and the bump to 7.3.4 on macOS), which is only a fraction of #629. The rest is already done.

Also, I was actually still waiting with that, because PyPy is almost releasing 7.3.5

Actually, most of #629 is already in master, as part of #633, also #660 as well. We had to update to 3.3.4 on linux, since we needed a newer image to get Auditwheel 4. It was also is blocking #521. These PRs were needed to get back to the latest versions of dependences and fix our update cycle. We were told "a week or two" for a 7.3.5 release more than two weeks ago, so (was) time to update. We pinned 7.3.3 on Windows by not changing archs automatically, that bug was about Windows. If it was a more general issue, pypy/manylinux would not have / should not have updated. Since we can't have a uniform PyPy version anyway, bumping macOS and dropping 3.6 seems reasonable.

Again, happy to force-push to the branch in #629 if you prefer that.

[henryiii]

PS: The rebase was a little harder than usual due to #630 going in in them meantime, which you were not very fond of, so I was also trying to help with that rather than ask you to do extra work.

[YannickJadoul]

Right, OK, now I think I see where this is coming from! Thanks for the extra explanation (and rebasing work; something tells me that wasn't obvious?), @henryiii!

PS: The rebase was a little harder than usual due to #630 going in in them meantime, which you were not very fond of, so I was also trying to help with that rather than ask you to do extra work.

And thanks for that, actually, now that I understand! :-) That now also makes sense.

So, two things to remark, from my side:

1. There are a few Windows-changes we might want to keep for PyPy 7.3.5 (coming soon?), so let's keep those in Update to PyPy 7.3.4 #629 and let's not close that? Either we repurpose that PR for the 7.3.5 testing and Windows changes, or we turn the leftovers into a new one?
2. Does this need to be backported to 1.x? Probably, because PyPy 3.6 should also be phased out there, or not? (Actually, I still need to catch up with those discussions, so maybe this is obvious; apologies, in that case).

Apart from that, good to merge, I think, yes!

P.S.: Even thought it's a bit of a bigger rebase, if you had left a comment and force-pushed, that would've also worked for me. But this is also fine, now that I understand why and how :-) Thanks again!

[henryiii]

P.S.: There are a few Windows-changes we might want to keep for PyPy 7.3.5

Ahh, I think that was part of why I also didn't feel safe force pushing - the Windows part is now not allowed to switch from 32 to 64 bit automatically, which "pins" it to 7.3.3, but eventually we will need the changes from #629 when we update to 7.3.5 and move to Windows 64 bit.

Does this need to be backported to 1.x?

There are two options - to backport rigorously (which is what I've done on boost-histogram, and it's worked very well), or to just backport as needed (which I've done with CLI11, and it's actually harder, IMO - if CI breaks, it's a total mess). I think we are leaning toward the second option; Python 3.5 is still available, for example. If someone did want to build PyPy3.6, they could use a 1-series release. But if something breaks (say, Python 3.5 or PyPy3.6, then I think we backport the drop). I don't think we are back porting the script fixes (other than a few important once), as we don't expect to bump the pins much there. (Up to others, mostly @joerick; personally happy to do backports if needed, including Python 3.5 dropping).