Don't append "m" ABI flag in Python 3.8

[rdb]

In Python 3.8, the m flag is no longer appended to the SOABI, since the ABI is longer influenced by enabling pymalloc. This PR should fix the ability to install Python 3.8 wheels on Windows. In Python 3.8, sys.abiflags is an empty string.

https://docs.python.org/dev/whatsnew/3.8.html#build-and-c-api-changes
https://bugs.python.org/issue36707

See also pypa/wheel#303

[chrahunt]

Hello, thank you for submitting a PR! We're tracking this activity over in pypa/packaging#172. This fix should target that library and then ideally it would get pulled into both pip and wheel.

IIUC, libraries built in release mode can get used in a debug interpreter in 3.8+, but not vice-versa. @vstinner describes the intended behavior here. So we would probably want to return a list of applicable tags (that is, both dm and m on a debug build), rather than remove them entirely. This would also need tests.

[rdb]

@chrahunt Note that this PR doesn't just cover debug but also the removal of the m ABI flag. This is unrelated to pypa/packaging#172 (and the cited e-mail still mentions the "m" flag because it predates that change). See bpo-36707. That change needs to get into the ensurepip shipped with Python 3.8 or it will be impossible to install properly formed Windows wheels in Python 3.8.

You're right that the addition of the d flag is now dependent on Py_TRACE_REFS instead of Py_DEBUG. I will change the PR accordingly. However, debug/release compatibility is out of scope of this PR, so targeting pypa/packaging#172 is not right.

Thank you for considering this.

[rdb]

@chrahunt I have opened issue pypa/packaging#180 to track this in that library, but not before realising that packaging.tags does not suffer from this bug; it returns the correct cp38 ABI instead of cp38m on Windows. This is because packaging.tags uses a different function that does not assume PyMalloc as the default.

I have changed the scope of this PR to only focus on the m tag to ensure that the discussion about debug compatibility does not confuse efforts to get this critical fix in.

I've updated the unit test.

[chrahunt]

You're right, this is unrelated to the change I linked before, sorry about that.

I made issue #6885 describing the problem in more detail. Can you please update the news file to reflect that issue?

@pradyunsg, assuming this looks OK and given the Python 3.8 release schedule (link), would this need to be in 19.2.3 or 19.3 to get into 3.8.0's ensurepip?

[rdb]

Thank you. Updated the bugfix number.

[pfmoore]

@rdb Thanks for spotting this and providing a fix!

[cjerdonek]

Question: is there a reason the sys.version_info < (3, 8) has to go after the call to get_flag()? It seems like this would be simpler with it before because then the sys.version_info < (3, 8) wouldn't need to be duplicated.

[pfmoore]

At a quick glance, that sounds like a reasonable tidy-up. A follow-up PR (as I just merged this as it stands) to clean this up would seem reasonable to me.

[cjerdonek]

Sounds good. (And the same type of change can be made in the following conditional as well.)

[rdb]

I agree, I was just following the example of the other version check below.

[cjerdonek]

I just filed this as PR #6889.

[pradyunsg]

@rdb Thanks a lot for this PR!

---

@chrahunt Good idea!

Let's do a 19.2.3 with just this change added and update the ensurepip module.

I see that the beta is on 26th. I'll try to get to both of those tasks by ~24,25 then.

[rdb]

Thanks for merging!

@pradyunsg Though it didn't appear to be important in my testing, setuptools.pep425tags also has the bugged version of get_abi_tag(), so I've replicated this PR there as well. In case it is used somewhere important after all, it might be good to get an updated setuptools into ensurepip as well.