Nathan Goldbaum

What is going wrong here is that ruamel.yaml now indicates that for 3.14 the ruamel.yaml.clib should be installed. It used not do that only for up to and including 3.13. Ah, I see! Maybe a simple fix would be to not do that on the free-threaded build: ``` diff -r b90370ceaa6d setup.py --- a/setup.py Wed Dec 17 20:59:34 2025 +0100 +++ b/setup.py Tue Dec 23 12:48:16 2025 -0700 @@ -13,6 +13,7 @@ # # init.py parser import sys +import sysconfig import os import datetime from textwrap import dedent @@...

What is going wrong here is that ruamel.yaml now indicates that for 3.14 the ruamel.yaml.clib should be installed. It used not do that only for up to and including 3.13. Ah, I see! Maybe a simple fix would be to not do that on the free-threaded build: ``` diff -r b90370ceaa6d setup.py --- a/setup.py Wed Dec 17 20:59:34 2025 +0100 +++ b/setup.py Tue Dec 23 12:48:16 2025 -0700 @@ -13,6 +13,7 @@ # # init.py parser import sys +import sysconfig import os import datetime from textwrap import dedent @@...

Maybe you missed that in my email: the code genrated with Cython 3.2.2, will not compile with Python 3.13.9t (and probably also not with 3.14.2t I did not try), so getting the sdist up to pypi is not going to solve anything. That's strange. It builds for me over here on my ARM Mac with both 3.13.9t and 3.14.2t, using the tip of the default branch: https://gist.github.com/ngoldbaum/f81290e334fd23c3314c2099f478b4dc https://gist.github.com/ngoldbaum/7fdadd022888790aba2ee1fc892d2a86 What operating system...

have commited the 3.2.2 generated version to this repo. I can tag it (0.2.16) if that helps and once i have time to investigate and update release a full 0.2.17., But I rather not do that if not necessary, as it is bound to generate questions why 0.2.16 is not on pypi I'm not sure merely tagging a release will help - there needs to be a new sdist on PyPI to solve the build issue. You could add cp314t wheels but the sdist alone would probably solve the issue for most people, who expect that they will...

Also, in case it helps, we've been maintaining some documentation on adding support for the free-threaded build at https://py-free-threading.github.io. You might find the docs on porting extensions the most useful: https://py-free-threading.github.io/porting-extensions/ There's also a page in the Cython documentation: https://cython.readthedocs.io/en/latest/src/userguide/freethreading.html

have commited the 3.2.2 generated version to this repo. I can tag it (0.2.16) if that helps and once i have time to investigate and update release a full 0.2.17., But I rather not do that if not necessary, as it is bound to generate questions why 0.2.16 is not on pypi I'm not sure merely tagging a release will help - there needs to be a new sdist on PyPI to solve the build issue. You could add cp314t wheels but the sdist alone would probably solve the issue for most people, who expect that they will...

One thing that would immediately help is to regenerate the bundled Cython code with a more recent version of Cython. The current code was generated with Cython 3.0.11, but the free-threaded build requires Cython 3.1 or newer.

I can confirm that this is happening. I'm not totally sure what is going wrong though. Perhaps the changes to the build to support zig builds in https://sourceforge.net/p/ruamel-yaml/code/ci/4bd5e2e783003d72327275235a663099474463c2/ broke something on the free-threaded build so that now the clib is an unconditional dependency somehow? https://sourceforge.net/p/ruamel-yaml-clib/tickets/44/ tracks supporting the free-threaded build in the C library. I think the free-threaded build has been broken using...