[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)

[LecrisUT]

I want to point out how important this is. If you run

$ python -c "import sys; import platform; print(sys.platform); print(platform.machine())"
win32
AMD64

Meaning your code-path would likely not work as intended. But if you add actions/setup-python it works more as intended.

[zooba]

$ python -c "import sys; import platform; print(platform.machine())"
AMD64

This result is a bit concerning... it means WMI (which is the authoritative system for getting OS information) isn't working, and so Python is having to fall back on the PROCESSOR_ARCHITECTURE environment variable, which (annoyingly) gets set to AMD64 for emulated processes.

We aren't seeing errors here in our (Python's) CI - could you run import _wmi; _wmi.exec_query("select Architecture from Win32_Processor") and share the result? (Which I'm assuming will be an exception, in which case the error code will be the most important thing.)

[zooba]

Or it means "python" is an old version. We wouldn't suggest trying to use Python 3.12 or earlier on ARM64 - there are builds, but not every fix has made it in. So 3.13 is roughly where it can reliably start from.

[kasper93]

Or it means "python" is an old version. We wouldn't suggest trying to use Python 3.12 or earlier on ARM64 - there are builds, but not every fix has made it in. So 3.13 is roughly where it can reliably start from.

You can see in the first posts, what versions of Python are available, this is output directly from the image.

[zooba]

You can see in the first posts, what versions of Python are available

The first post doesn't tell me which one python refers to, only which ones are available and which one py will select.

[kasper93]

only which ones are available and which one py will select.

Fair, my point was that the newest available seems to be 3.12, which is below recommended by you 3.13.

The first post doesn't tell me which one python refers to

> python --version
Python 3.9.13

CommandType Name       Version        Source
----------- ----       -------        ------
Application python.exe 3.9.13150.1013 C:\hostedtoolcache\windows\Python\3.9.13\x64\python.exe

[zooba]

Thanks. And yeah, unfortunately the reason for py.exe (and the new replacement global python.exe we're about to release) existing is to avoid the issue of PATH being messed up, as it is here.

We definitely don't want Python developers relying on the default python.exe here, but that may end up just being a case of education rather than technical fixes. There's nothing wrong with using Python 3.9 emulated on ARM64, unless you're expecting it to know that it's on ARM64, which it doesn't. Later versions of Python should detect the platform correctly.

I believe actions/setup-python works fine, and there's no harm in people getting used to using that when the Python version (or architecture) matters to them. For people who aren't sensitive to that, they're probably better off with a x64 version that has prebuilt wheels available (though preferably not an end-of-life version like 3.9...)

[pareenaverma]

Thank you all for your patience. We are adding python 3.11 through 3.14 arm native builds to the image in addition to updating the x64 version of python that is available on the image. We plan on making the new image available in the next couple weeks and will update the issue here once it's published.