installers on ARM64 suggest wrong folders #90900
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = None closed_at = None created_at = <Date 2022-02-13.23:50:52.347> labels = ['type-bug', 'expert-installation', 'OS-windows', '3.11'] title = 'installers on ARM64 suggest wrong folders' updated_at = <Date 2022-03-16.02:36:53.862> user = 'https://github.com/conioh'
activity = <Date 2022-03-16.02:36:53.862> actor = 'conio' assignee = 'none' closed = False closed_date = None closer = None components = ['Installation', 'Windows'] creation = <Date 2022-02-13.23:50:52.347> creator = 'conio' dependencies =  files =  hgrepos =  issue_num = 46744 keywords = ['patch'] message_count = 9.0 messages = ['413199', '413262', '413266', '413294', '414500', '414502', '414629', '414689', '415325'] nosy_count = 6.0 nosy_names = ['paul.moore', 'tim.golden', 'python-dev', 'zach.ware', 'steve.dower', 'conio'] pr_nums = ['31677', '31803'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue46744' versions = ['Python 3.11']
The text was updated successfully, but these errors were encountered:
Thank you for your work on bringing Python to Windows on ARM64.
I recently installed it an noticed some strange behaviours.
On ARM64 Windows 11 the recent prerelease (3.11.0a5, post bpo-33125) acts in a way I believe is wrong: Checking the install for all users checkbox causes the installer to suggest the
The folder for programs that are native for the platform is simply
So on ARM64 Windows the ARM64 Python should go into the native Program Files folder which is
A closely related issue is that the installer for x64 Python wants to install into
The x86 acts as as should be expected and wants to install into
But there's no "Program Files (x64)", so where should the x64 version on ARM64 machines go?
I argue that the x64 version should go into
(The dotnet team also had this problem, and they decided similarly.)
Thanks for the additional info! I agree with the design you propose.
It would be much easier to make the ARM64 install use the tagged
I'll try and take a look at what the detection code would be like and
Though I think the naming scheme that includes platform identification is better, if all installers include the platform name unconditionally, including both amd64 and arm64, that's also an improvement. (So the names will be
The convention would be uniform, there won't be a collision between arm64 and amd64 on the same system, and amd64 won't get preferential treatment even on non-amd64 systems.
I do wonder though - is there no platform detection code today in the installer? Would the x86 versions install into "PythonXY-32" even on 32-bit Windows? If there already is, then adding a call to
Yeah, currently the only detection that happens is OS version, and just
Any dynamic detection code would have to go into
However, I think we should consider the 32/64-bit install directory
We should probably also display a notice in the installer when
Posted half a PR for this, which is worth taking in itself, but doesn't completely address the whole change. It will install to the correct ProgramFiles folder on ARM64 now, but still with the suffix.
If we are to take the rest of the change (use "-amd64" for AMD64 builds on ARM64 OS), it has to be ready for beta 1. There's still time, but absent a major issue from *not* doing it, we want to avoid changing on-disk layout during beta/RC.
Thank you very much, Steve.
I took a look but didn't get to making the patch. I'm happy to see it was just removing the
For the second issue, even though I prefer it the way I said (unqualified = native), since
(i) the default is using the value of
I think you are right in keeping it out for now. I wouldn't insist on it. If there comes a
I did notice one small issue when I tried to build Python for ARM64 following your message
The help message for
If you could change either the help string or the flag itself so they'd math it would be great.
Uppercase is nice because it is consistent with
If there's no problem or difficulty in changing the arguments for
I opened a PR for this change (#31803). I'd appreciate your comments and/or approval.
I didn't add anything to the NEWS.d folder since it seems to me like something completely internal to the build process and so minor not worth mentioning there.