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 actions/setup-python#973 and depends on a patched version of actions/python-versions. See Quansight-Labs/free-threaded-compatibility#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 <#913 (comment)>, 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.