-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to PyPy 7.3.4 #629
Update to PyPy 7.3.4 #629
Conversation
Something to think about, btw: since this is just a patch version increase of PyPy, do we actually want to keep building EDIT: Same goes for 32-bit Windows. |
The targets have changed in a patch version before (3.7 got added). I think it's fine to change on PyPy - 3.6 (due to NumPy dropping it) is rapidly getting harder to use. Wait, are there no 32 bit binaries for Windows? They should have both, not drop 32 for 64? I know 32-bit CPython was rather popular (maybe heavily due to the fact it was the default download choice until very recently more than due to OS requirements). |
Right, but adding something is more backwards compatible, ofc. But yeah, fair enough; I guess it's PyPy's decision to release it as 7.3.4 (and ofc not worth breaking the ABI version for).
I had already popped onto IRC to ask, yes. Nothing that seems to secret, so I'll post it here:
I'll just ping @mattip, in case you'd like to convince him about the popularity of 32-bit :-) |
I am willing to be convinced to release 32-bit windows, but it would have to be by a user who can explain how it is worth the (admittedly small) maintenance burden). |
@Czaki, I don't remember the details, but I'm seeing "PyPy patch not applied". Do you know by heart whether we can remove that patch and workaround, or should I check the PR that introduced it again? |
Where did you see this? In log? |
Yep. The "Get some sample wheels" step of GHA:
|
Patch are here: https://github.com/joerick/cibuildwheel/blob/master/cibuildwheel/resources/pypy_venv_27.patch and https://github.com/joerick/cibuildwheel/blob/master/cibuildwheel/resources/pypy_venv.patch If I good remember there was a problem that in virtualenv compiler cannot find "Python.h" maybe current version fix it already. |
Yeah, didn't you submit a PR/issue to PyPy? Any idea whether that got merged/resolved? |
OK, I stopped being lazy for a second and looked it up myself: #501 (comment) |
OK, our |
So, something's wrong with the headers of pypy2.7-v7.3.4rc1-win64.zip; reported on IRC already. Apart from that, things seem to be working :-) |
The headers are produced as part of an optional module in PyPy called cpyext that provides the C-API compatibility layer. We do not compile pypy2.7 on win64 with cpyext. Would it be hard to do I started work on this in the win64-cpyext-default branch, but then someone pointed out that tp_hash and hashes in general on python2.7 are |
But the main task of |
I guess we could plainly not offer PyPy Python 2.7 on Windows, then? I think Oh, no, wait. There's still
(sorry to hear about that btw; sounds like a horrible issue :-/ ) |
Biased for pybind11, but not having Python.h kills pybind11 extensions. Not the best solution quite yet, but I guess needs to be mentioned: dropping Python 2 support would fix this issue...
ROOT has been fighting with this for a while, still don't have a 64-bit windows build due to it. It is clearly written in the standard that long does not have to be 64-bits, but that hasn't stopped assumptions based on Linux/macOS or 32-bit Windows. |
Right. How many projects have a user base that needs testing/releasing with PyPy on windows for python2.7? Before I spend a few days solving this, I would like to know it is going to be used. |
Yeah, dropping 2.7 would of course also work. Or dropping PyPy 2.7 on Windows, for now? (or probably just everywhere to be consistent) |
Honestly, I don't know how much of a user base PyPy2 has. With NumPy requiring 3.7 now, it's likely a bit limited. And 2.7 on Windows is traditionally small due to other compiler reasons (and the fact it's easier to upgrade on Windows than having a build-in Python 2 on Linux/macOS). I do think we are going to be dropping PyPy2 when dropping CPython 2.7 in 2.0. But that's not quite here yet. |
So, we're still failing on PyPy 2.7's missing headers on Windows. @joerick, where would you like to go with this? Still build 2.7 32-bit for now, using 7.3.3? Or just drop PyPy 2.7 on Windows, or ... ? |
I would vote for dropping it until you hear from users. Reasoning: If you drop PyPy2.7 for windows, you would quickly hear from any users who need it, and then PyPy could invest the effort to support cpyext for that verison. Any other work-around will encourage users to stay with an older version. |
c0cfa38
to
c293941
Compare
@mattip, sure. This seems to be working. The downside is that users also won't be able to build cffi wheels for PyPy 2.7 (on Windows), ofc. After all, this is just a decision to be made by PyPy, I'd say. (Unless you want us to support PyPy 2.7 (for cffi wheels), without C API headers; then it'd be up to @joerick to decide whether that's risking a lot of complaints about failing builds.) |
@YannickJadoul let's give it a shot. If it turns out lots of people want to package for pypy2.7 on windows, we can think harder about it. |
@@ -115,8 +115,8 @@ def __init__(self, arch_str: ArchStr): | |||
self.arch = arch_str | |||
|
|||
def update_version_windows(self, spec: Specifier) -> ConfigWinCP: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This'll probably take some more changes. But I'm guessing we'll have to wait for a final release of 7.3.4 to fix it.
I'm cool to drop 2.7 on Windows, too. We're dropping 2.7 as a whole in #596 anyway, so it probably won't be a big issue :) |
Waiting for pypy/manylinux#16 to pull this out of "draft" |
For the record:
See https://mail.python.org/pipermail/pypy-dev/2021-April/016150.html So we probably ought to be skipping 7.3.4 and immediately pin 7.3.5? |
That makes sense, although it may be a week or two until 7.3.5 is released. |
Thanks, @mattip! I don't think we're in a huge hurry to merge this, currently? |
Not if it's broken. :) |
Seems I broke GitHub by force-pushing the Windows-only changes to this branch of the closed PR. Huh. Anyway, I'll open a new draft with those leftover changes that weren't in #666 |
Still in draft, but preparing for when a release is made. The Python 3.6-compatible version of PyPy was dropped, as the Python 3.7-compatibility was deemed completed (cfr. https://doc.pypy.org/en/latest/release-v7.3.4.html).
I still need to get an updated manylinux docker image.