[Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

[Gregory P. Smith]

On Thu, Feb 14, 2019 at 11:38 AM Steve Dower <steve.dower at python.org> wrote:

> As part of adding ARM32 support for Windows, we need to enable
> cross-compilation in distutils. This is easy enough, though it requires
> somehow getting the target platform as well as the current platform.
>
> Right now, the change at https://github.com/python/cpython/pull/11774
> adds a get_target_platform() function for this and updates (as far as I
> can tell) all uses of get_platform() to use this instead. I would rather
> just change get_platform() to return the target platform.
>
> The current docs are somewhat vague on exactly what this function does,
> and I suspect have been mostly written from an "always build from
> source" mentality that may have implied, but not explicitly considered
> cross-compilation.
>
> https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform
>
> "Return a string that identifies the current platform. This is used
> mainly to distinguish platform-specific build directories and
> platform-specific built distributions."
>
> So it says "current" platform, explicitly says that "os.uname()" is the
> source, but then goes on to say:
>
> "For non-POSIX platforms, currently just returns sys.platform."
>
> Which is incorrect, as sys.platform is always "win32" always but
> get_platform() already returns "win-amd64" for 64-bit builds.
>
> And also:
>
> "For Mac OS X systems the OS version reflects the minimal version on
> which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET
> during the build of Python), not the OS version of the current system."
>
> So it seems like this function is already returning "the default
> platform that should be used when building extensions" - ignoring bugs
> in libraries that monkeypatch distutils, the "--plat-name" option should
> entirely override the return value of this function.
>
> Given this, does it seem to be okay to have it determine and return the
> target platform rather than the host platform? Right now, that would
> only affect the new target of building for win-arm32, but I would also
> like to update the documentation to make it more about how this value
> should be used rather than where it comes from.
>
> Any objections or concerns?
>

To alleviate confusion long term I'd love it if we could deprecate the
unqualified get_platform() API and point people towards always being
explicit about get_target_platform() vs get_current_platform().

There are valid reasons for people to be expecting either target or current
return values from get_platform(), but I agree with you, having it return
the target platform *feels* more likely to be what people want.  It'd be
worth auditing a random sample of people's calls of this API in open source
projects to confirm that intuition.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190214/68ba943f/attachment.html>