Just for share: https://ft-checker.com/
For now, it only checks whether the Top 1000 PyPI packages can be installed on Free-threaded CPython, but it still gives a reasonably accurate view of what builds successfully.
I’m sharing the website here in case it’s useful to others.
The status will be updated irregularly.
Please let me know if I should handle something more correctly.
(Sorry for these basic questions. I’m generally unfamiliar with what it actually takes for a package to “support free threading.”)
I’m curious if your checker can detect if the code was modified to support free threading or if it just runs the equivalent of ./configure && make test? Is there any metadata associated with packages which would suggest the author(s) have specifically addressed potential issues related to free threading?
From the about page:
The Python Compatibility Checker runs daily tests on the popular PyPI libraries, attempting to build and test each library with development versions of Python 3.13t and 3.14t.
I have to modify the explain now 
Well, running whole TSAN tests for those libraries would be unrealistic as a personal project because it will require super huge infra costs.
But my minimum target for this project would be running each project’s unit tests and that would be possible if I try in my budget.
Native extensions need to explicitly mark that they support running without the GIL by setting the Py_mod_gil module slot during module init. The default setting is Py_MOD_GIL_USED, which causes the interpreter to enable the GIL at runtime when the module is imported. If you set it to Py_MOD_GIL_NOT_USED, the interpreter lets you import the module and keep the GIL disabled.
Pure-Python code doesn’t have any equivalent, under the assumption that Python code is automatically safe from data races (although not race conditions or racey algorithms).
There was some discussion about creating a trove classifier that package authors can add to indicate that they support the free-threaded build. IMO trove classifiers aren’t terribly useful so I’m personally not pushing that forward.
It’s also worth remembering that thread safety issues can also be triggered on the GIL-enabled build, so it’s more a question of whether a package supports running under threading at all. It’s valid not to support that, although then IMO users should have warnings in documentation somewhere, since threads are always an import threading away.
For single-threaded use, the free-threaded build and the GIL-enabled build should run pure-python code identically. C extensions should also run identically in single-threaded use, assuming the extension isn’t using ABI details that aren’t present in the free-threaded build.
I haven’t looked through Donghee’s analysis yet, but I predict the main source of breakage at this point is likely the lack of a Cython 3.1 release and the lack of CFFI support on the free-threaded build. The former leads to build errors when pip creates a build environment using the current Cython stable release. The latter leads to build errors when CFFI defaults to building an extension with the limited API, which isn’t supported yet on the free-threaded build. Any other C extensions or binding generators that default to using the limited API also won’t work out of the box without some adjustment on the free-threaded build.
If you want to chime in on Pre-PEP: Standardizing test dependency and command specification as having a need for a standardized way to run tests I’m sure it would be appreciated. 
Thanks to @henryiii there are trove classifiers for free-threading now: feat: add free-threading classifiers by henryiii · Pull Request #195 · pypa/trove-classifiers · GitHub
I’m not implying it’s a good metric for free-threading support, but it could become a reasonable proxy.
Since it has just been merged, I’d expect the number of packages using the classifier to be close to zero at this time.