Python launcher should prefer local architecture

[jaraco]

Bug report

Bug description:

In brettcannon/python-launcher#425 (comment), I learned that on Windows for ARM, if both Python for x64 and Python for ARM are installed, the Python launcher prefers the x64 version.

> py -0p
 -V:3.13t *       C:\Program Files\Python313\python3.13t.exe
 -V:3.13t-arm64   C:\Users\jaraco\AppData\Local\Programs\Python\Python313-arm64\python3.13t.exe
 -V:3.13          C:\Program Files\Python313\python.exe
 -V:3.13-arm64    C:\Users\jaraco\AppData\Local\Programs\Python\Python313-arm64\python.exe

I understand the ARM version is experimental. When it becomes non-experimental, and probably before then, the Python launcher should prefer version that aligns with the host machine's architecture instead of preferring versions that are run under a compatibility layer.

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[zooba]

When it becomes non-experimental, and probably before then, the Python launcher should prefer version that aligns with the host machine's architecture

Becoming non-experimental is the trigger for it to start preferring ARM64 builds on ARM64; everything pivots at that point. And hopefully it'll happen in the new launcher implementation as part of PEP 773 (my prototype already supports it, it just isn't enabled yet, nor is it published) rather than in the old one, which means there won't be anything to fix here.

Other feedback has suggested that defaulting to selecting the experimental install but not defaulting to installing it is also suboptimal, so there isn't really a good answer for "when should we choose a non-default install by default" other than "never". Always selecting the default version unless the caller overrides is considered correct behaviour, so changing that would be a feature anyway.

And FWIW, it'll become non-experimental when regular users are not going to immediately fail. Right now, I still believe too many will fail at the first package install, and so it's out there for package developers to update their releases, but not

[jaraco]

Thanks for the clarification.

And FWIW, it'll become non-experimental when regular users are not going to immediately fail. Right now, I still believe too many will fail at the first package install, and so it's out there for package developers to update their releases, but not

Personally, I've been using the experimental ARM installers for Windows since I got my first ARM-based Mac and started running Windows under UTM, including running my shell under it. I don't believe I've encountered a single failure due to the architecture. Or, it least I thought that was the case, but now that I look into it more deeply, I must have been using the AMD64 version.

Indeed, I can confirm the arm version is unsuitable, as I seem to be unable to run pip install -t:

C:\Users\jaraco>py -V:3.13-arm64 -m pip install -t ~/.local/pip-run pip-run
No suitable Python runtime found
Pass --list (-0) to see all detected environments on your machine

I can be patient while issues are worked out in the experimental release.

I understand that new architectures can introduce problems and take time to work out the issues, but let me raise another issue in the naming.

The current naming lists the AMD64 version as the default. In fact, you can't even invoke it by architecture:

C:\Users\jaraco>py -V:3.13-amd64
No suitable Python runtime found
Pass --list (-0) to see all detected environments on your machine

In my opinion, the naming should aim to by symmetrical and not show preference to the legacy / compatibilty form.

For example, when Microsoft released Windows XP 64-bit, they recognized that 64-bit would eventually be the future and so created:

• C:\Program Files (x86) for legacy, and
• C:\Program Files (with 64-bit implied) for the future.

That was a smart, future-leaning choice. It meant that a lot of things installed under the compatibility layer would be tagged, but that long-term, x86 could be retired and the system would be left without the architecture tag. I was sad to learn that they made a different choice when naming PROGRAMFILES(ARM). That means that ARM will be perpetually second-class to AMD in how the file system is laid out.

I'd like to avoid the same fate for python launcher. At the very least, I'd like to see the architecture selection have symmetry, but long term, I'd prefer for the architecture selection to be an expert feature and not exposed except where necessary.

---

Revisiting my environment, I've confirmed that I have in fact been installing the ARM-based Python on this machine (only back to 3.13b1)... and that it does seem to work well for me in most cases. It was only after installing the AMD64 version and the ARM64 version using winget that I started having problems.

And interestingly, if I install 3.13 for all users, it installs to C:\Program Files\Python313-arm64 by default. That's kinda weird. Why is it in the AMD64 program files but with an ARM tag? Anyway, I override that and install it as C:\Program Files\Python 3.13, because I want this architecture-aligned version to be the default version.

With that installed, I'm able to do a lot of things, like install pyyaml, which doesn't have ARM for Windows binaries. But then I went to upgrade pip and ran into problems in distlib with missing executable wrapper scripts. So maybe what's going on is I'd previously adopted Python for ARM before pip was aware of ARM and so everything was falling back to compatibility support, but trying to update pip fails.

---

Sorry this post has gone rambling in so many directions, and thanks for considering my concerns.

[zooba]

The current naming lists the AMD64 version as the default. In fact, you can't even invoke it by architecture

The spelling is -V:3.13-64, which someone else decided upon before ARM64 became an option. I spent some time thinking about how to best deal with platforms in the new launcher, since they're all over the place. It's possible to support both -64 and -amd64 (and -arm64 for ARM), but I'm not sure that's helpful for users (in a lot of places it will bloat the number of names shown). And there's no nice way to make -64 be either AMD64 or ARM64. I actually completely deprecated the -64 suffix, since it was nothing but a distraction, but other people wanted it brought back.

Right now, the new launcher uses platform suffixes on every tag, but will match based on the current default - so 3.13 matches 3.13-64 when the default platform tag is -64. (And right now the default is always -64, but can be configured and will eventually switch at startup.)

C:\Users\jaraco>py -V:3.13-arm64 -m pip install -t ~/.local/pip-run pip-run
No suitable Python runtime found

This suggests that your ARM64 install isn't registered properly. It's nothing to do with pip - that error comes from py. See whether py -0 shows your ARM64 install?

I was sad to learn that they made a different choice when naming PROGRAMFILES(ARM). That means that ARM will be perpetually second-class to AMD in how the file system is laid out.

Actually, that directory is for 32-bit ARM, and it isn't used for ARM64. I believe splitting Program Files is considered a mistake, these days, and so all 64-bit binaries, whether ARM64 or AMD64, go into PROGRAMFILES.

Detecting cross-installation was not worth the effort just for per-machine installs, which is why the ARM64 install always gets the suffix.

If PEP 773 is accepted, all installs will be per-user (unless the user works around it, which is fine if they want), and will always have the suffixes (even -64 on AMD64). If it's not accepted, I'm still going to look for ways to simplify the installer to the point where we can actually fix the showstopping bugs, which will likely rule out "clever" code to handle side-by-side installs of Python on ARM64 (and will likely relegate path customisation to command-line invocations). But that's all hypothetical as long as the SC haven't looked yet - I really don't know what they'll do if they insist on keeping the current messed up installer situation...