Skip to content

Free threaded support #12555

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

ngoldbaum
Copy link
Contributor

@ngoldbaum ngoldbaum commented Mar 4, 2025

Fixes #12489

@ngoldbaum
Copy link
Contributor Author

I guess because I'm not using the tests nox session I don't get coverage reports on CI "for free".

@alex
Copy link
Member

alex commented Mar 6, 2025 via email

@ngoldbaum
Copy link
Contributor Author

@alex it looks like all the wheel builds are successful except for win32 and armv7. See these actions runs on my fork:

win32: https://github.com/ngoldbaum/cryptography/actions/runs/16601346439/job/46961605807?pr=2
armv7: https://github.com/ngoldbaum/cryptography/actions/runs/16601346439/job/46961606173?pr=2

Not sure what to do about these. Do you have any ideas?

I also disabled some manylinux2014 builds due to the issue that should be fixed by python-cffi/cffi#184.

I also wasn't able to run ppc64le on my fork so let's see if there are any issues there.

Are you OK with me marking all the rust PyModules with gil_used = false in this PR? We're relying on upstream guarantees from PyO3 in all the rust code.

@alex
Copy link
Member

alex commented Jul 29, 2025

IDK what's going on with the win32 one. The armv7 one seems to suggest the build is building an aarch64 wheel, which is obviously just wrong.

And yes, going to gil_used=False is fine, we don't rely on it.

@alex
Copy link
Member

alex commented Jul 30, 2025

it occurs to me that the gil_used=false should be good to split off from this and land now

@ngoldbaum
Copy link
Contributor Author

ngoldbaum commented Jul 31, 2025

it occurs to me that the gil_used=false should be good to split off from this and land now

I'll put this in along with the new CFFI version constraints in pyproject.toml. We can sort out the win32 build issues later but it would be nice to at least get things in a state with no build errors or unnecessary warnings.

EDIT: actually on second thought let's try to sort out the build issues first...

@alex
Copy link
Member

alex commented Jul 31, 2025

At this point I think we're just waiting for the cffi release! Thanks for your work here!

@ngoldbaum
Copy link
Contributor Author

At this point I think we're just waiting for the cffi release! Thanks for your work here!

While the remaining build issues here aren't very fun I've been telling people that working on the CFFI reverse dependencies is the programming equivalent of peeling plastic off of new electronics: so satisfying to fix stuff that's been broken for a year or so!

When you say "waiting for a CFFI release" does that mean you're not comfortable doing a cryptography release until there's a CFFI 2.0.0 final release? I think as long as there's an explicitly dependency on the beta release in cryptography's pyproject.toml, everything should be fine downstream. Unless I'm missing something.

@ngoldbaum
Copy link
Contributor Author

ngoldbaum commented Jul 31, 2025

OK win32 is fixed. That came down to uv not selecting free-threaded python unless you explicitly opt into it. I added --python where appropriate.

I tried building the armv7 wheel manually in a docker container on my Mac, but frustratingly the build succeeds there and produces an armv7 wheel:

root@18e5360863db:/cryptography# mkdir tempwheelhouse
root@18e5360863db:
/cryptography# OPENSSL_DIR="/opt/pyca/cryptography/openssl" OPENSSL_STATIC=1 uv build --python=/opt/python/cp314-cp314t/bin/python --require-hashes --build-constraint=.github/requirements/build-requirements.txt --sdist -o tempwheelhouse
Building source distribution...
Running maturin pep517 write-sdist --sdist-directory /root/cryptography/tempwheelhouse
🍹 Building a mixed python/rust project
🔗 Found pyo3 bindings with abi3 support
📡 Using build options locked from pyproject.toml
📦 Including files matching "CHANGELOG.rst"
📦 Including files matching "CONTRIBUTING.rst"
📦 Including files matching "docs//*"
📦 Including files matching "src/_cffi_src/
/.py"
📦 Including files matching "src/_cffi_src/**/
.c"
📦 Including files matching "src/_cffi_src//*.h"
📦 Including files matching "Cargo.toml"
📦 Including files matching "Cargo.lock"
📦 Including files matching "src/rust/
/Cargo.toml"
📦 Including files matching "src/rust//Cargo.lock"
📦 Including files matching "src/rust/
/.rs"
📦 Including files matching "tests/**/
.py"
📦 Built source distribution to /root/cryptography/tempwheelhouse/cryptography-46.0.0.dev1.tar.gz
cryptography-46.0.0.dev1.tar.gz
Successfully built tempwheelhouse/cryptography-46.0.0.dev1.tar.gz
root@18e5360863db:~/cryptography# OPENSSL_DIR="/opt/pyca/cryptography/openssl" OPENSSL_STATIC=1 uv build --python=/opt/python/cp314-cp314t/bin/python --wheel --require-hashes --build-constraint=.github/requirements/build-requirements.txt tempwheelhouse/cryptography-46.0.0.dev1.tar.gz
Building wheel from source distribution...
Running maturin pep517 build-wheel -i /root/.cache/uv/builds-v0/.tmpbDRLqK/bin/python --compatibility off
🍹 Building a mixed python/rust project
🔗 Found pyo3 bindings with abi3 support
🐍 Found CPython 3.14t at /root/.cache/uv/builds-v0/.tmpbDRLqK/bin/python
📡 Using build options locked from pyproject.toml
⚠️ Warning: CPython 3.14t at /root/.cache/uv/builds-v0/.tmpbDRLqK/bin/python does not yet support abi3 so the build artifacts will be version-specific.
Compiling target-lexicon v0.13.2
Compiling proc-macro2 v1.0.95
Compiling unicode-ident v1.0.18
Compiling shlex v1.3.0
Compiling once_cell v1.21.3
Compiling pkg-config v0.3.32
Compiling vcpkg v0.2.15
Compiling libc v0.2.174
Compiling autocfg v1.5.0
Compiling foreign-types-shared v0.1.1
Compiling openssl v0.10.73
Compiling foreign-types v0.3.2
Compiling cc v1.2.30
Compiling heck v0.5.0
Compiling cfg-if v1.0.1
Compiling bitflags v2.9.1
Compiling itoa v1.0.15
Compiling indoc v2.0.6
Compiling memoffset v0.9.1
Compiling unindent v0.2.4
Compiling cryptography-key-parsing v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-key-parsing)
Compiling cryptography-openssl v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-openssl)
Compiling base64 v0.22.1
Compiling self_cell v1.2.0
Compiling quote v1.0.40
Compiling pyo3-build-config v0.25.1
Compiling pem v3.0.5
Compiling syn v2.0.104
Compiling openssl-sys v0.9.109
Compiling cryptography-cffi v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-cffi)
Compiling pyo3-ffi v0.25.1
Compiling pyo3-macros-backend v0.25.1
Compiling pyo3 v0.25.1
Compiling cryptography-rust v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust)
Compiling openssl-macros v0.1.1
Compiling asn1_derive v0.22.0
Compiling asn1 v0.22.0
Compiling cryptography-x509 v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-x509)
warning: [email protected]: In file included from /opt/_internal/cpython-3.14.0rc1-nogil/include/python3.14t/Python.h:92,
warning: [email protected]: from /root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/target/release/build/cryptography-cffi-723ec3746b75d810/out/_openssl.c:58:
warning: [email protected]: /opt/_internal/cpython-3.14.0rc1-nogil/include/python3.14t/cpython/longintrepr.h: In function '_PyLong_CompactValue':
warning: [email protected]: /opt/_internal/cpython-3.14.0rc1-nogil/include/python3.14t/cpython/longintrepr.h:135:12: warning: conversion to 'Py_ssize_t' {aka 'int'} from 'unsigned int' may change the sign of the result [-Wsign-conversion]
warning: [email protected]: 135 | sign = 1 - (op->long_value.lv_tag & _PyLong_SIGN_MASK);
warning: [email protected]: | ^
Compiling pyo3-macros v0.25.1
Compiling cryptography-crypto v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-crypto)
Compiling cryptography-x509-verification v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-x509-verification)
Compiling cryptography-keepalive v0.1.0 (/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/src/rust/cryptography-keepalive)
Finished release profile [optimized] target(s) in 4m 51s
📦 Including files matching "CHANGELOG.rst"
📦 Including files matching "CONTRIBUTING.rst"
📦 Including files matching "docs//*"
📦 Including files matching "tests/
/*.py"
📦 Built wheel for CPython 3.14t to /root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/target/wheels/cryptography-46.0.0.dev1-cp314-cp314t-linux_armv7l.whl
/root/cryptography/dist/.tmpfGqU11/cryptography-46.0.0.dev1/target/wheels/cryptography-46.0.0.dev1-cp314-cp314t-linux_armv7l.whl
Successfully built dist/cryptography-46.0.0.dev1-cp314-cp314t-linux_armv7l.whl

so I still have no idea what's going wrong on the CI builds...

@alex
Copy link
Member

alex commented Jul 31, 2025

That's correct that we don't want to ship a release until this is in a cffi release.

@ngoldbaum
Copy link
Contributor Author

I reported a bug against maturin: PyO3/maturin#2701

@alex
Copy link
Member

alex commented Jul 31, 2025

is there any chance it's an issue in the manylinux image, and that the 3.14-freethreaded binary in the armv7l image is accidentally aarch64?

@ngoldbaum
Copy link
Contributor Author

is there any chance it's an issue in the manylinux image, and that the 3.14-freethreaded binary in the armv7l image is accidentally aarch64?

looks like that's indeed what's happening: pypa/manylinux#1825 (comment)

@ngoldbaum
Copy link
Contributor Author

Apologies for the noise here, I'm trying to debug the armv7 issue.

@alex
Copy link
Member

alex commented Aug 5, 2025 via email

@ngoldbaum ngoldbaum force-pushed the free-threaded-support branch from 269aa12 to dae8ad2 Compare August 6, 2025 01:27
@ngoldbaum
Copy link
Contributor Author

Looks like that fixed it! There's one unrelated failure. I'll go ahead and do a separate PR for the manylinux-entrypoint fix.

@ngoldbaum
Copy link
Contributor Author

OK, I think this should be ready whenever CFFI does a release. I'll try to rebase every now and then since this will bitrot quickly whenever the CI or wheel building config changes.

@ngoldbaum ngoldbaum force-pushed the free-threaded-support branch from cec0246 to 1fe8f0a Compare August 13, 2025 16:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Support free-threaded CPython (3.14t)
2 participants