Free threaded support

[ngoldbaum]

Towards fixing #12489.

Adds free-threaded CI using a hacky workaround to avoid building against the version of cffi on PyPI.

xref #12590

[ngoldbaum]

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

[alex]

Great

…

On Thu, Mar 6, 2025 at 5:03 PM Nathan Goldbaum ***@***.***> wrote: @ngoldbaum commented on this pull request. ________________________________ In src/rust/src/padding.rs: > @@ -110,6 +110,62 @@ impl PKCS7PaddingContext { } } +#[pyo3::pyclass] I'll cherrypick the Rust ports and make them their own PRs and keep the free-threading-specific stuff in this PR. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[ngoldbaum]

@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]

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]

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