#554 with Python 3.14.0 free-threading, ruamel.yaml==0.18.17 fails to installs

[Even Rouault]

with Python 3.14.0 free-threading, ruamel.yaml==0.18.17 fails to installs whereas it works with ruamel.yaml==0.18.16

with setuptools-68.2.2.post20251220 and pip 25.3

$ python3 -m pip install ruamel.yaml==0.18.17
Collecting ruamel.yaml==0.18.17
Using cached ruamel_yaml-0.18.17-py3-none-any.whl.metadata (27 kB)
Collecting ruamel.yaml.clib>=0.2.15 (from ruamel.yaml==0.18.17)
Using cached ruamel_yaml_clib-0.2.15.tar.gz (225 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Using cached ruamel_yaml-0.18.17-py3-none-any.whl (121 kB)
Building wheels for collected packages: ruamel.yaml.clib
Building wheel for ruamel.yaml.clib (pyproject.toml) ... error
error: subprocess-exited-with-error

× Building wheel for ruamel.yaml.clib (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [441 lines of output]
/tmp/pip-build-env-m7cvuc71/overlay/lib/python3.14t/site-packages/setuptools/dist.py:759: SetuptoolsDeprecationWarning: License classifiers are deprecated.
!!

          ********************************************************************************
          Please consider removing the following classifiers in favor of a SPDX license expression:

          License :: OSI Approved :: MIT License

          See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
          ********************************************************************************

  !!
    self._finalize_license_expression()
  running bdist_wheel
  running build
  running build_py
  creating build/lib.linux-x86_64-cpython-314t/ruamel/yaml/clib
  copying ./setup.py -> build/lib.linux-x86_64-cpython-314t/ruamel/yaml/clib
  copying ./__init__.py -> build/lib.linux-x86_64-cpython-314t/ruamel/yaml/clib
  copying ./LICENSE -> build/lib.linux-x86_64-cpython-314t/ruamel/yaml/clib
  running build_ext
  building '_ruamel_yaml' extension
  creating build/temp.linux-x86_64-cpython-314t
  gcc -pthread -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -fPIC -I/tmp/venv/include -I/home/even/install-python-3.14.0-nogil/include/python3.14t -c _ruamel_yaml.c -o build/temp.linux-x86_64-cpython-314t/_ruamel_yaml.o
  In file included from _ruamel_yaml.c:1222:
  _ruamel_yaml.h:10: warning: "PyString_CheckExact" redefined
     10 | #define PyString_CheckExact PyBytes_CheckExact
        |
  _ruamel_yaml.c:1062: note: this is the location of the previous definition
   1062 |   #define PyString_CheckExact          PyUnicode_CheckExact
        |
  _ruamel_yaml.c:2162:80: error: unknown type name ‘__pyx_vectorcallfunc’; did you mean ‘vectorcallfunc’?
   2162 | static CYTHON_INLINE PyObject *__Pyx_PyVectorcall_FastCallDict(PyObject *func, __pyx_vectorcallfunc vc, PyObject *const *args, size_t nargs, PyObject *kw);
        |                                                                                ^~~~~~~~~~~~~~~~~~~~
        |                                                                                vectorcallfunc
  _ruamel_yaml.c: In function ‘__pyx_pf_6ruamel_4yaml_4clib_12_ruamel_yaml_get_version_string’:
  _ruamel_yaml.c:4089:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
   4089 |   __pyx_v_value = yaml_get_version_string();
        |                 ^

[Nathan Goldbaum]

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 the clib for a while.

[Anthon van der Neut]

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.

Since ruamel.yaml.clib is not available as .whl for the free threaded version, pip will try to build it from source.

So AFAICT nothing to do with the changes for ruamel.yaml.clibz, and that is unlikely to compile for threaded without changes, without me making changes (for Cython).

If you just use ruamel.yaml for it preserving format on round-trip, you don't need the clib extension and I recommend installing ruamel.yaml with --no-deps

[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
@@ -656,6 +657,8 @@
https://hynek.me/articles/conditional-python-dependencies/
"""
ep = self._pkg_data.get('extras_require')
+ if sysconfig.get_config_var("Py_GIL_DISABLED"):
+ del ep[':platform_python_implementation=="CPython" and python_version<"3.15"']
return ep
```

I just tested with this patch and it avoids the issue. There's probably a nicer way to generate the key we want to remove without hard-coding it.

Unfortunately there isn't a way to declare this using static metadata, that will require something like PEP 780: https://peps.python.org/pep-0780/