[Distutils] distutils.util.get_platform() for Windows

[Mark Hammond]

Phillip writes:

> Because distutils' get_platform() isn't really clear about the
> distinctions that setuptools makes explicit, about version
> compatibility.  In a sense, distutils' get_platform assumes that no
> platform can run any other platform's code, even though this isn't so
> for at least Mac OS.
>
> For example, if a 'win32' package can be used on 'win64', setuptools
> needs to know this -- but distutils has no clue and doesn't care,
> because distutils doesn't *do* anything with platform information
> except generate filenames (including build directory file names).

IIUC, this is a little tricky - in this specific example, it depends on what
Python architecture is installed.  On an x64 system, a 32bit Python and
32bit extensions can be installed - but an x64 extension can not.  However,
if an x64 version of Python itself is installed, 32bit extensions can not
be.  Note that both x64 and x32 builds of Python on Windows report 'win32'
for sys.platform and 'nt' for os.name.

So from this perspective, it seems no compatibility can be recorded between
the architectures, as they can never be mixed.

> Notice that setuptools has *two* different get_*_platform APIs,
> because of this distinction, plus a "compatible_platforms" function;
> distutils doesn't have any of that.

I understand that is how distutils works now.  I'm questioning if that is
the way distutils should keep working in the future.  Is there some reason
I'm missing why we can't *add* this functionality to distutils and have
setuptools consume it?  Or is the (defacto) intent that cross-compilation
only be supported via setuptools?  I've no objection to this being the case,
but "explicit is better than implicit" <wink>

> So if we move away from win32 as a platform designator, I need to
> understand *precisely* what values will replace it, so that
> compatible_platforms will be able to support them correctly.

Yes, part of this process would be deciding the precise strings that would
be returned.

> In general, platform strings are an underspecified area of the
> distutils, so if we change anything about them, I'd like to improve
> the specification.  I'm not happy with adding more code whose
> behavior is implementation-defined, as it leaves me with no way to
> figure out what platforms are compatible with what.

I've no problem with that - but best I can tell, no compatibility could be
recorded for this specific example, so this problem doesn't really depend on
a better way of capturing compatibility between platforms.

Cheers,

Mark