-
-
Notifications
You must be signed in to change notification settings - Fork 157
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
Add free-threading support #462
Conversation
In the Windows free-threading test, pytest appears to fail with
I have no idea what that might be about. |
- run: pip install tox | ||
- run: tox run -e ${{ matrix.tox || format('py{0}', matrix.python) }} | ||
--discover C:\Python313\python3.13t.exe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be restricted to Windows-only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, though it does not seem to hurt on other platforms.
(The tox docs say that --discover
means "for Python discovery first try these Python executables".)
TBH, at this point, I do not remember if the --discover
is even necessary (though I suspect that would have removed it if it were not.) There was a lot of flailing involved in getting tox to find the manually-installed version of python on Windows (including, also, the manual addition of the install directories to $PATH).
An alternative to the use of --discover
might be to rename the installed python3.13t.exe
to python3.13.exe
.
This whole PR could, admittedly, use a bit of cleanup.
Someone who knows their way around Windows and PowerShell could probably do a better job on this than I.
(And, hopefully, some time soon, actions/setup-python
will support installing no-GIL versions. See actions/setup-python#771 for progress and some hints.)
I do have Windows, is there a way to download built artifacts from CIBW? A |
For unknown reasons, though not totally unsurprisingly, a recent virtualenv seems necessary for success with free-threaded tests.
Co-authored-by: Adam Turner <[email protected]>
c345597
to
53795eb
Compare
@AA-Turner Yes. If one looks at the workflow logs from the actions/upload-artifact step, there is a download URL. I've just updated my play.free-threading-cibuildwheel to match the latest cibuildwheel config in The download URL for the Windows job is https://github.com/dairiki/markupsafe/actions/runs/11072940568/artifacts/1988029015 |
Seems like this was integrated into #461 |
I'm fine with just Linux for now. MarkupSafe doesn't actually do anything with threading or the GIL, so the tests aren't really doing much besides confirming that it imports. Once |
I see a segfault locally as well, just from |
Has anyone tried/managed to test a (free-threading) cibuildwheel-built wheel on Windows yet? E.g. #462 (comment) |
Good call. Installing that wheel and running the tests passed. I'm so confused, but I guess I can release those wheels. What is cibuildwheel doing that I'm not locally? |
This is an attempt to address #460. Mostly, I followed the instructions that @AA-Turner linked to there.
I looked over _speedups.c. My non-expert eye did not see anything that didn't look nogil-safe, so I just added the
Py_MOD_GIL_NOT_USED
declaration to the extension module.The matrix in the tests.yaml workflow has been expanded to included free-threading versions of python3.13 under Linux and Windows.
The Linux tests work.
The Windows tests do not, for reasons that I do not understand.
I played with enabling free-threading cibuildwheel builds in a separate branch, and that seems to just work. (Though I have not tested any of the resulting wheels to verify that they are usable.)
Fixes #460