[vadikmironov]

Follow-up to #4442.

python-build-standalone debug (Py_DEBUG) archives for Linux and macOS
add a d ABI flag to some names: include/python3.14d and
lib/libpython3.14d.so (.dylib on macOS), or td for free-threaded
debug builds. The runtime repo only knows the release names, so a debug
runtime registered with python.single_version_platform_override does
not work for C code: current_py_cc_headers fails with
Python.h: No such file or directory and current_py_cc_libs with
missing input file '...//:lib/libpython3.14.so'. On a macOS host, the
repo rule's install_name_tool step also looks for the release dylib.

To fix, the repo rule checks the extracted archive for the d include
dir and passes that to the runtime macro, which uses the d names. The
macro also sets abi_flags on py_runtime and py_cc_toolchain,
because <AUTO> only derives t. Extensions built against the debug
headers need a debug interpreter, so they get the debug SOABI (for
example cpython-314d-x86_64-linux-gnu) and wheel ABI tag (cp314d).

Windows debug archives use other names (python_d.exe,
python314_d.dll) and are not handled here. Will be addressed
separately.

• Also registers a debug runtime for tests in MODULE.bazel and adds
  //tests/toolchains:debug_runtime_test, which builds an extension
  against it and imports it.

[vadikmironov]

I prepared this with Claude Code. It wrote the change and the test, built against the python-build-standalone 3.14 debug and free-threaded debug archives on Linux x86_64, and ran the new test there. macOS is checked only against the archive layout (include/python3.14d, lib/libpython3.14d.dylib); the install_name_tool step has not been run. I reviewed it myself, and I'll answer review comments myself.

[vadikmironov]

Raised #4472 for this. 3.14.4 is the highest other than 3.14.10 in the runtimes manifest.

[aignas]

What about adding an additional flag to the matching algorith so that if users would like to not use the or use them exclusively, they can do that?

Do these runtimes provide something that would be of interest to the users?

[rickeylev]

adding an additional flag

I'm +1 on being able to set a flag so that a debug runtime can be chosen, but lets defer that to another PR. There's like 3 different ways we could have it specified:

• --compilation_mode=dbg (bazel builtin flag)
• --py_pbs_distribution=debug (reuse our existing flag)
• --py_debug=yes (new flag)

...but we can figure that out separately. This PR will at least make them usable.

Do these runtimes provide something that would be of interest to the users?

I think its mostly of interest to people writing C extensions, e.g. helping debug why an extension is misusing memory.

[rickeylev]

LGTM. Github has been queueing jobs for hours, so no idea when this will actually end up in the merge queue.