The string processing is a bit icky. It would be convenient to just pass these values (SOABI,Py_NOGIL) from a C to Python, but it wasn't clear to me where to put that (i.e., insys,_imp,_winapi or someplace else)

I agree. Maybe a good option would be putting them on_winapi and then simply loading them in_init_non_posix?

sys.flags?

Isn'tsys.flags for command line flags?

sys.implementation then? We added these namespaces specifically to be extensible

But this information (SOABI,Py_NOGIL, etc) doesn't seem quite right there, I think. Though maybe this is just my interpretation.

I have a prototype locally to export this information in_winapi, avoiding any public API changes. It doesn't feel amazing either, but 🤷.

Really, this should just be exposed by sysconfig directly, which may involve a C_sysconfig module that exports this information out to Python, or something else. It's unfortunate that there's such a large discrepancy between how Makefile and Windows builds work 😞. This is kind of a mess, and we should probably try to unify things, it's just... hard, and a lot of work. I'm a bit tired of all this 😕

I moved some of these to_winapi. A_sysconfig C module might also make sense, but it would be very small.

I don't like this being here, I'd rather it be in the sys module. It's not a Windows API

What do you think about putting it in a_sysconfig C module?

I think we're probably past due having one of those. We already smuggle constants intogetbuildinfo.c (git info) andsysmodule.c (VPATH) on Windows, so may as well put them all into a_sysconfig.c that is importable.

Make it a built-in module though, not its own .pyd.PC/config.c lists the modules that are directly linked in, so it'll look like one of those.

You can see the smuggling inPCbuild/pythoncore.vcxproj (search forGITVERSION= andVPATH=). Doesn't necessarily have to be done the same way, but copying it is going to be the easiest way to ensure incremental builds keep working normally.

I've moved the computation to a_sysconfig C module. Thanks for the pointer toPC/config.c -- that made it easier. I don't think we need to smuggle data fromPCbuild/pythoncore.vcxproj like we do forGITVERSION andVPATH here.

(note for the future)

I think we can move this to_init_config_vars, I am sure it will end up there soon anyway. The only thing to keep in mind is that we allow the POSIX config vars module (eg._sysconfigdata__linux_x86_64-linux-gnu) to be overwritten (to help in cross-compilation) by setting_PYTHON_SYSCONFIGDATA_NAME, and we should raise an error if the value given by the user is different from what we computed.
To be even more cautious, I think we should probably save the originalsysconfigdata name in the C module, as attributes likesys.implementation, etc., are often monkey patched when cross-compiling. If needed, people working on cross-compilation should also monkey patch the_sysconfig module explicitly, or better, just monkey patchsysconfig.get_config_vars.

You don't need to do it in this PR, I just wanted to write this down, especially to document the non-obvious issue with_PYTHON_SYSCONFIGDATA_NAME.
I don't think relying on Makefile variables is great, for a ton of reasons, meaning the new sysconfig API (GH-103480) will very likely use_sysconfig.config_vars on other platforms, so I expect the_PYTHON_SYSCONFIGDATA_NAME issue to be relevant soon.

This is one of the things I wanted to avoid 😅

I think it's probably okay, but one thing to keep in mind is thatEXT_SUFFIX is usually used as the extension to give native modules. We likely want to make sure we are setting it to the one that includesSOABI, not a different one (eg. theabi3 one). In this case, I think we should probably be okay since we know Windows will always have one, and put it in the first entry.