On macOS Big Sur (11.y.z), the return value of distutils.util.get_platform() records in some cases the minor version of OS. For example:

- with a Python 3.9 built on macOS 10.0.1, distutils.util.get_platform() will return macosx-11.0-x86_64
- with a Python 3.9 built on macOS 10.1.0, distutils.util.get_platform() will return macosx-11.1-x86_64
- if MACOSX_DEPLOYMENT_TARGET=11.1 was set at build time, then distutils.util.get_platform() will return macosx-11.1-x86_64
- if MACOSX_DEPLOYMENT_TARGET=11 was set at build time, then distutils.util.get_platform() will return macosx-11-x86_64

This has important consequences for wheel and pip, which use the return value to determine platform tags: https://github.com/pypa/wheel/issues/385

From the API Reference (https://docs.python.org/3/distutils/apiref.html), it is not clear what the expect return value is. Given that previously, the return value of distutils.util.get_platform() was dependent only on the macOS major version, I would expect this to be the case. Therefore, distutils.util.get_platform() should return macosx-11-x86_64 on all Big Sur (macOS 11.x.y) versions.

PS: This is not directly related to another issue with MACOSX_DEPLOYMENT_TARGET
https://bugs.python.org/issue42504

What I think should be the logical solution to this bug:
make distutils.util.get_platform() return "macosx-11-x86_64" on all Big Sur (macOS 11.x.y) versions, independent of the minor OS version.

However, if the Python developers decide that this should not (for some reason) be the case, then this should be clearly documented. But I believe that would create trouble for other packages downstream.

Actually, I can find some distribution of Python where the minor version is returned, for example on Apple macOS 10.15.4:

/usr/bin/python3 -c 'import distutils.util; print(distutils.util.get_platform())' 
macosx-10.14.6-x86_64

Therefore maybe I misunderstand and there is no guarantee on the form of this return value

IMHO sysconfig.get_platform() and distutilis.util.get_platform() should always return a version with a major and minor number on macOS.

Could you add more information on the system where you get a version number that includes the micro version?

And to repeat myself: having "11.0" as the version a number is ship that has sailed, this is already used on PyPI (see PyObjC's latest wheels).

> having "11.0" as the version a number is ship that has sailed

I understand. What is needed is consistency and predictability.

Now, the next minor releases will be 11.0.1 (that has shipped already), 11.1.0 (will ship soon), then either 11.1.1 or 11.2.0 (we don't know). The next major version will of course be 12.0.0.

The question is: for 11.1.x or 11.2.x, which are minor updates, should the pypi/wheel tags increase to 11_1 and 11_2, or stay at 11_0? Has that been decided, and will be applied consistently? (11_0 makes more sense, and it is what wheel is currently applying)

> Now, the next minor releases will be 11.0.1 (that has shipped already), 
> 11.1.0 (will ship soon), then either 11.1.1 or 11.2.0 (we don't know). The 
> next major version will of course be 12.0.0.
> 
> The question is: for 11.1.x or 11.2.x, which are minor updates, should 
> the pypi/wheel tags increase to 11_1 and 11_2, or stay at 11_0? Has 
> that been decided, and will be applied consistently? (11_0 makes more 
> sense, and it is what wheel is currently applying)

It depends :-)

We should advise everyone to build for deployment target 11.0 (and or 12.0 next year *if necessary*), but IMHO we shouldn't enforce this is in the stdlib.

If someone decides they want to build with MACOSX_DEPLOYMENT_TARGET=11.3 that's their choice and should be reflected in the result of get_platform(). We shouldn't default to that though just because you're building on macOS 11.3. 

Something we can work on is an informational PEP that describes the best way to build wheels on macOS, in cooperation with the PyPA, delocate, ciwheelbuild, and whoever else is interested in this.  And then try to teach the tooling to do the right thing.

In most cases it should be fairly easy to create wheels that target an earlier version of macOS (like the installers on Python.org).  The annoying part are (C) libraries with configure scripts that can detect and use functions that aren't available on the deployment target. For most libraries that I've created bindings for (most of them in-house) this hasn't been a problem in practice, but that's a very limited sample. 

Sorry about going of on a tangent, none of this is relevant for this particular issue ;-)

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools