I think I added sysconfig.get_config_var('SOABI') for Windows in:

• gh-88402: Add new sysconfig variables on Windows (GH-110049) #110049.

In particular, the relevant comments are here: #110049 (comment).

The problem is that Windows uses a different format and the _d tag isn't part of what we internally consider the SOABI. Debug libraries look like:

foo_d.cp313-win_amd64.pyd

where cp313-win_amd64 is the SOABI and the _d tag is attached to the name.

Yeah, the filename format is just different. Looking at sysconfig.getconfigvar("EXT_SUFFIX").startswith("_d") might be the most relevant Windows-specific check, or just do what packaging.tags does (which might be nothing, meaning there are no debug-specific wheels for Windows).

IMHO, debug builds of CPython aren't worth supporting to the point where I'd put wheels on PyPI. Is there a new use case here that I haven't heard about? Or are we just looking for 100% completeness where it isn't really useful?

I have a project where during development, I use setuptools to create a wheel containing a debug build of an extension module and is specific to the debug build of Python. The wheel is named something like example-1.0.0-cp312-cp312d.whl, which I then install using the debug build of Python. I find that doing this makes the extension module easier to debug.

With Python 3.12, SOABI on Windows is empty, so setuptools uses its own logic to construct the ABI tag cp312d if the debug build of Python is used. With Python 3.13, now that SOABI is set, setuptools does something different; it takes the SOABI value of cp313-win_amd64 and uses the part before the hyphen, cp313 as the ABI tag. This misses the d flag when the debug build of Python 3.13 is used. I was trying to figure out whether a change should be made to CPython or setuptools.

Based on the above comments, it's clear that setuptools should make a change. Thanks!

The critical compiler flag is /MDd (vs /MD for a non-debug build), which makes you require the CPython debug ABI.

If you pass /MD, even with debug info turned on and optimisations turned off, you get the regular ABI but with an easily debuggable extension module. The only thing you lose is native assert() statements and some debugging features of the C runtime (which are partially controlled by the _DEBUG/NDEBUG preprocessor variables, which are automatically set by /MDd//MD but often specified manually which can become problematic).

Using a debug build of CPython is only really necessary to debug CPython itself. If you believe that CPython does not contain the bug, you don't need its debug build.

Thanks, that's good to know. However, a complication is that my extension module links to a DLL which exports C++ functions, and I'm building that DLL using /MDd because I often debug into that DLL's code as well, and I like the memory management checks that /MDd provides in the DLL. To ensure C++ ABI compatibility, the extension module must also be built with /MDd. I suppose my options then are to build both the extension module and the DLL with /MDd and continue to use the debug build of CPython, or build both the extension module and DLL with /MD.