Support the free-threaded build

[ngoldbaum]

Currently if you do pip install bcrypt on the free-threaded build, you'll get a completely broken install:

``` (local) ± pip install bcrypt Collecting bcrypt Downloading bcrypt-4.2.0.tar.gz (24 kB) Installing build dependencies ... done Getting requirements to build wheel ... done Preparing metadata (pyproject.toml) ... done Building wheels for collected packages: bcrypt Building wheel for bcrypt (pyproject.toml) ... done Created wheel for bcrypt: filename=bcrypt-4.2.0-cp313-cp313t-macosx_14_0_arm64.whl size=233184 sha256=93a6252508624a3549986d7db41a1cf44e3272e1412e9d3bf7cee1c75cb6320e Stored in directory: /Users/goldbaum/Library/Caches/pip/wheels/1f/4d/ce/1ca481535e020fde94ff2f57782354b0786af9dcca0fb6d7f7 Successfully built bcrypt Installing collected packages: bcrypt Successfully installed bcrypt-4.2.0 goldbaum at Nathans-MBP in ~ (local) ○ python Python 3.13.0 experimental free-threading build (main, Nov 5 2024, 16:45:19) [Clang 16.0.0 (clang-1600.0.26.3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import bcrypt [1] 67189 segmentation fault python goldbaum at Nathans-MBP in ~ (local) ○ lldb $(pyenv which python) -- -c "import bcrypt" (lldb) target create "/Users/goldbaum/.pyenv/versions/3.13.0t/bin/python" Current executable set to '/Users/goldbaum/.pyenv/versions/3.13.0t/bin/python' (arm64). (lldb) settings set -- target.run-args "-c" "import bcrypt" (lldb) r Process 67337 launched: '/Users/goldbaum/.pyenv/versions/3.13.0t/bin/python' (arm64) Process 67337 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000183b93610 libsystem_platform.dylib`_platform_strcmp + 64 libsystem_platform.dylib`_platform_strcmp: -> 0x183b93610 <+64>: ldr q0, [x0], #0x10 0x183b93614 <+68>: ldr q1, [x1], #0x10 0x183b93618 <+72>: cmeq.16b v1, v0, v1 0x183b9361c <+76>: and.16b v0, v0, v1 Target 0: (python) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000183b93610 libsystem_platform.dylib`_platform_strcmp + 64 frame #1: 0x0000000100baeabc libpython3.13t.dylib`_PyImport_ResolveNameWithPackageContext + 76 frame #2: 0x0000000100a8cee0 libpython3.13t.dylib`_PyModule_CreateInitialized + 280 frame #3: 0x00000001001044ec _bcrypt.cpython-313t-darwin.so`pyo3::sync::GILOnceCell$LT$T$GT$::init::h257e11b4d9895c8d + 48 frame #4: 0x00000001000d14a8 _bcrypt.cpython-313t-darwin.so`pyo3::impl_::pymodule::ModuleDef::make_module::h366cc7983064c099 + 300 frame #5: 0x00000001000c5118 _bcrypt.cpython-313t-darwin.so`PyInit__bcrypt + 56 frame #6: 0x0000000100bb5cf8 libpython3.13t.dylib`_PyImport_RunModInitFunc + 60 frame #7: 0x0000000100bb3238 libpython3.13t.dylib`import_run_extension + 116 frame #8: 0x0000000100bb4cf8 libpython3.13t.dylib`_imp_create_dynamic + 492 frame #9: 0x0000000100a8ba00 libpython3.13t.dylib`cfunction_vectorcall_FASTCALL + 268 frame #10: 0x0000000100b675a8 libpython3.13t.dylib`_PyEval_EvalFrameDefault + 13328 frame #11: 0x0000000100a29e74 libpython3.13t.dylib`object_vacall + 304 frame #12: 0x0000000100a29c74 libpython3.13t.dylib`PyObject_CallMethodObjArgs + 104 frame #13: 0x0000000100bb1724 libpython3.13t.dylib`PyImport_ImportModuleLevelObject + 1064 frame #14: 0x0000000100b6bc98 libpython3.13t.dylib`_PyEval_EvalFrameDefault + 31488 frame #15: 0x0000000100b63e90 libpython3.13t.dylib`PyEval_EvalCode + 360 frame #16: 0x0000000100b5ff8c libpython3.13t.dylib`builtin_exec + 1224 frame #17: 0x0000000100a8bae4 libpython3.13t.dylib`cfunction_vectorcall_FASTCALL_KEYWORDS + 164 frame #18: 0x0000000100b675a8 libpython3.13t.dylib`_PyEval_EvalFrameDefault + 13328 frame #19: 0x0000000100a29e74 libpython3.13t.dylib`object_vacall + 304 frame #20: 0x0000000100a29c74 libpython3.13t.dylib`PyObject_CallMethodObjArgs + 104 frame #21: 0x0000000100bb1724 libpython3.13t.dylib`PyImport_ImportModuleLevelObject + 1064 frame #22: 0x0000000100b6bc98 libpython3.13t.dylib`_PyEval_EvalFrameDefault + 31488 frame #23: 0x0000000100b63e90 libpython3.13t.dylib`PyEval_EvalCode + 360 frame #24: 0x0000000100bdbc5c libpython3.13t.dylib`run_eval_code_obj + 180 frame #25: 0x0000000100bdb6fc libpython3.13t.dylib`run_mod + 224 frame #26: 0x0000000100bd958c libpython3.13t.dylib`_PyRun_SimpleStringFlagsWithName + 176 frame #27: 0x0000000100bfe238 libpython3.13t.dylib`Py_RunMain + 1760 frame #28: 0x0000000100bfec6c libpython3.13t.dylib`pymain_main + 324 frame #29: 0x0000000100bfed0c libpython3.13t.dylib`Py_BytesMain + 40 frame #30: 0x00000001837db154 dyld`start + 2476 ```

Ultimately this is happening because the version of bcrypt on pypi points at PyO3 0.22, which can't support the free-threaded build. It looks like you've already updated to PyO3 0.23 on main, so the next release should fix the crashes that projects depending on bcrypt will run into.

Separately, we should look at adding CI for free-threaded Python 3.13 and look at setting up multithreaded tests.

[reaperhulk]

@alex was looking at this and discovered that setup-python doesn't currently have 3.13t, which is a bit unfortunate.

[alex]

I guess this means we should do a release so that at least it doesn't crash for people. Then we can do follow ups to test it, and set gil_used = false, and produce official wheels.

[ngoldbaum]

If you're ok with temporarily switching out setup-python, we've forked it at https://github.com/quansight-labs/setup-python. The fork applies https://github.com/actions/setup-python/pull/973 and depends on a patched version of actions/python-versions. See https://github.com/Quansight-Labs/free-threaded-compatibility/issues/98 and linked issues for additional context.

We're hoping that github will at least publicly comment on supporting free-threaded python soon.

I totally understand as a security-minded project if you'd prefer to stick with the "official" actions workflows.

[reaperhulk]

4.2.1 is now released so we shouldn't crash 😄

I'm not a huge fan of merging a fork of such a core actions dep, although with full hash pinning (assuming the forked action does hash pinning too!) then the risk isn't much. What do you think Alex?

[alex]

I'm also not a fan, though it's primarily driven from a concern that it's more likely to become unmaintained and we'll forget.

On Tue, Nov 19, 2024, 3:19 PM Paul Kehrer @.***> wrote:

4.2.1 is now released so we shouldn't crash 😄

I'm not a huge fan of merging a fork of such a core actions dep, although with full hash pinning (assuming the forked action does hash pinning too!) then the risk isn't much. What do you think Alex?

— Reply to this email directly, view it on GitHub https://github.com/pyca/bcrypt/issues/913#issuecomment-2486668087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAGBH5CNKJEWHFH6MHAPL2BOMLVAVCNFSM6AAAAABSC5CKQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWGY3DQMBYG4 . You are receiving this because you were mentioned.Message ID: @.***>

[ngoldbaum]

There hasn't been a need to do any releases on our fork yet, but our plan is to keep things in sync with upstream and for dependabot to pick up on releases. I have NumPy set up to use our fork to test free-threading and we use hash pinning and dependabot over there as well.

Ping @andfoy who has taken on maintaining the fork.

The plan is also to do a final release announcing the end of the fork so people see it in dependabot. We'll contact all the projects we can find using it on public repos with PRs to switch back to setup-python whenever they add support.

[reaperhulk]

Okay, given that commitment (and the diligence you've shown so far, thank you again!) I think I'm fine with saying we can take a temporary dep on that to unblock CI/wheel builders for free threaded wheels. Does your current fork also support linux arm64 3.13t? We have runners that need that.