[windows-11-arm] Install native arm64 Python

[kasper93]

Type of issue

• Error when running a workflow.
• Request for additional tools or software for an existing image.
• Request for a new image, Linux or Windows.
• Other

Describe the issue
Python installed in windows-11-arm is x86_64 and emulated.

To Reproduce

PS > py -0    
 -V:3.12 *        Python 3.12 (64-bit)
 -V:3.12-32       Python 3.12 (32-bit)
 -V:3.11          Python 3.11 (64-bit)
 -V:3.11-32       Python 3.11 (32-bit)
 -V:3.10          Python 3.10 (64-bit)
 -V:3.10-32       Python 3.10 (32-bit)
 -V:3.9           Python 3.9 (64-bit)
 -V:3.9-32        Python 3.9 (32-bit)
 -V:3.8           Python 3.8 (64-bit)
 -V:3.8-32        Python 3.8 (32-bit)
 -V:3.7           Python 3.7 (64-bit)
 -V:3.7-32        Python 3.7 (32-bit)

Expected behavior
There should be ARM64 version available. For example

-V:3.13-arm64 *  Python 3.13 (ARM64)

Desktop (please complete the following information):

• windows-11-arm

[zooba]

For whoever reviews this issue, I just want to point out that the python.org release of Python for Windows ARM64 is experimental so that you can put it in this image, not so that you'll ignore it.

We want regular users to ignore it for now, but tools and package developers should be testing and building with it. The worst thing that could happen is if a million school children start installing it on their new laptops and all the library developers are caught by surprise. That's why it's experimental.

[kasper93]

The whole windows-11-arm is experimental as far as I can see. And the point imho is to test native environment and build with native tools. Also if there is a need for x86 emulated version of Python it can also be installed, but I expect the primary should be native arm64.

If I want to use x86 Python I can use native x86 image...

[zooba]

Also if there is a need for x86 emulated version of Python it can also be installed, but I expect the primary should be native arm64.

It depends on what you're doing. If Python is just part of your build process for a C++ app, then you probably don't care about the architecture, but you want one that's going to have precompiled wheels available.

If you're actually doing a Python project, then yeah, you probably want a native ARM build by default. Which is why I agreed with you that it should be on there (I'm just preempting a disagreement that I've heard over the last few years of trying to grow adoption of the ARM64 builds).

[Nielsbishere]

@zooba Actually, I'm using conan for building and this does cause issues. Because if the host is different than the build target it might use a different build routine (to build native binaries for tools required in building itself), this is the case with LLVM / DXC (DirectX Shader Compiler) and does actually add build time and might not always work. It'd be very nice if python was arm64 so that conan would know during build time that this is an arm64 system trying to build for arm64, so it doesn't have to do any duplicate work or build for the wrong target.
For anyone else having problems with this, it seems that only the default image has problems with it so you can use the setup-python action to dodge this: https://github.com/orgs/community/discussions/155713#discussioncomment-12867390.

[zooba]

Because if the host is different than the build target it might use a different build routine ... It'd be very nice if python was arm64 so that conan would know during build time that this is an arm64 system trying to build for arm64, so it doesn't have to do any duplicate work or build for the wrong target.

Sure, I accept that this is a genuine issue (and again, I'm not arguing against putting ARM64 Python on these machines, but I'm arguing for it, which would help you).

However, the underlying cause is that Conan (apparently, based on your description) needs some way to tell it what the target platform should be, so that it doesn't have to guess. If it knew (perhaps because you provided a setting) that the target was ARM64, it could select things properly and make sure that it builds the right thing.

[Nielsbishere]

yes, I also provide it that setting, the problem is that there'll be a mismatch between the host and the build so it spends more time because it has to also build the native binaries alongside the target (because it has to run these binaries on the host to build for the target)