Backport PyPy 3.9 support for pyo3 0.15 #2262
Conversation
|
Downgrading clap to 2.33 works. |
I think that would not be possible in the context of #2260 as this is about supporting old platforms like RHEL 6 using rustc 1.41? |
messense
added
the
CI-no-fail-fast
|
Yes, MSRV should not change in patch releases. |
|
I tried to bless the ui tests on macOS, but it still failed on CI. |
Co-authored-by: messense <messense@icloud.com>
|
All green 🎉 Thanks @messense for your work :) I think this is done now? |
|
🎉 🎉 🎉 Would it be helpful for us to do a CI run on pyca/cryptography with this branch to verify everything looks good? |
|
I was just about to ask 😄 Yes, that's a good idea 👍 |
|
Ok testing PR up at pyca/cryptography#7062 |
|
Looks like there's an issue with pypy3.7 7.3.9, several tests are failing with |
|
It looks like these tests go through the datetime api 😬 Your CI uses This may be a case of #2217 |
|
I don't think we use the pyo3/C-API for handling datetimes directly, AFAIK everywhere we process datetimes we do it like this: https://github.com/pyca/cryptography/blob/main/src/rust/src/x509/common.rs#L663 |
|
Uh, strange. I don't think this PR introduces any difference between PyPy 3.7 and PyPy 3.8 ..... 🤔 @davidhewitt, any ideas? 🤷 |
|
Confirmed that the tests pass on pypy3.7 7.3.7, but I'd like to understand what the regression on 7.3.9 is :-/ |
src/callback.rs
Outdated
| #[cfg(all(PyPy, not(Py_3_8)))] | ||
| { | ||
| const PYPY_GOOD_VERSION: [u8; 3] = [7, 3, 8]; | ||
| let version = py | ||
| .import("sys")? | ||
| .getattr("implementation")? | ||
| .getattr("version")?; | ||
| if version.compare(crate::types::PyTuple::new(py, &PYPY_GOOD_VERSION))? | ||
| == std::cmp::Ordering::Less | ||
| { | ||
| let warn = py.import("warnings")?.getattr("warn")?; | ||
| warn.call1(( | ||
| "PyPy 3.7 versions older than 7.3.8 are known to have binary \ | ||
| compatibility issues which may cause segfaults. Please upgrade.", | ||
| ))?; | ||
| } | ||
| } |
There was a problem hiding this comment.
I think this is the one place where we're changing the behavior of the code on pypy3.7. I don't have an obvious reason this would cause a crash, but it does jump out to me that we're doing this import+operations on every single function invocation.
There was a problem hiding this comment.
I don't have an obvious reason this would cause a crash,
I think it's most likely that this set an exception/warning when it shouldn't have. For example, if you raise a warning during __traverse__, you can segfault.
|
Alternatively... computers cursed. CI's now passing just fine on 7.3.9 |
CC @mattip |
|
Thanks! @mejrs |
|
I've pushed a commit to support PyPy 3.7 v7.3.8+ instead of pinning to v7.3.7, because this was agreed as the correct solution to the binary compatibility issues in https://foss.heptapod.net/pypy/pypy/-/issues/3688#note_181074 |
|
I'll continue to bump the pyca/cryptography side for any changes here -- it's still green (I'm not going to leave more status updates unless that changes :-)) |
|
I think this is now good to go! Unless I hear otherwise, I'll put this live some time later today. |
- Updated from version 0.15.1 to 0.15.2
- Update of rootfile
- Changelog
## [0.15.2] - 2022-04-14
### Packaging
- Backport of PyPy 3.9 support from PyO3 0.16. [#2262](PyO3/pyo3#2262)
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Fixes #2260