pypa
Py_UNICODE_SIZE / WITH_PYMALLOC / Py_DEBUG on Windows
Originally reported by: Daniel Holth (Bitbucket: dholth, GitHub: dholth)
Wheel uses these flags to try to find the d/m/u values for tags, but they don't appear to be available on Windows. Do something else instead. Same issue reported against pip.
- Bitbucket: https://bitbucket.org/pypa/wheel/issue/171
The d/m/u values are meaningless on Windows. Only the debug flag was ever an option, but it is not available via sysconfig as it is purely a build-time option (i.e. it's not written down in the source code anywhere).
Debug binaries are generated with _d suffixes (e.g. python_d.exe, _ssl_d.pyd), so even if they are included in a wheel, they won't be loaded at runtime. '_d.pyd' in importlib.machinery.EXTENSION_SUFFIXES is the most correct way to check, but sys.executable.lower().endswith('_d.exe') is going to work on older versions.
Alright, so should wheel handle the debug flag somehow? Use your check to figure out if this is a debug build and add "d" to the ABI tag?
Personally, I'd be just fine with using the check and refusing to make a wheel at all ("don't ship debug builds"). That said, there are legitimate uses for debug wheels, though I think that PyPI should certainly reject them.
Perhaps the best detection is to look at any .pyd files being added, since that's what determines whether the wheel will work or not. If all the extension module names end with _d (which I know could still be a legitimate name... unfortunately it's the convention that we have :( ) then mark the entire wheel as debug only. But then pip would need separate handling for "what tags can I install" vs. "what tags should I generate" - maybe that's okay?
Or alternatively, don't do any detection but provide a way for users to specify the flag if they have some need for a debug-only wheel. I suspect this is an incredibly rare situation, especially since it doesn't exist right now, and nobody is really going to miss it. Probably the only reason it's noticed at all is because of the warnings that these flags aren't found on Windows, so suppressing those warnings may be all that's really warranted here :)
As a tangent, note that the warnings go to stderr and at least in some cases Appveyor seems to treat (by default, at least in some cases?) any (powershell) script that writes to stderr as failure (https://help.appveyor.com/discussions/problems/10014-false-build-fail-status#comment_44099248), which caused a bit of head-scratching to me. Of course this could be considered as a limitation of Appveyor and can be worked around; still, I'd appreciate if the warnings were just suppressed.
