Skip to content

Installer Suggests Wrong Folder When Upgrading on Windows on ARM #95587

Closed

Description

@ElectricalBoy

Bug report

When using Windows Installer to upgrade Python on Windows on ARM, installer suggests user-specific install location (i.e., %USERPROFILE%\AppData\Local\Programs) even if previous version was installed system-wide (i.e., C:\Program Files)

Steps to repro

  1. Download and install previous release of Python (e.g., 3.11.0b1) using Windows ARM64 Installer. Make sure to check "Install for all users" option under "Advanced Options" page.
  2. Download and open newer version (e.g., 3.11.0b5) Windows ARM64 Installer.
  3. Observe the path the installer tries to use with "Upgrade Now" option.

Expected behavior

Newer version installer correctly picks up install directory of previous version (i.e., C:\Program Files\Python311-arm64)

Actual behavior

Installer incorrectly tries to use user-specific install location (i.e., %USERPROFILE%\AppData\Local\Programs\Python\Python311-arm64) instead.

Workaround

Manually check "Install for all users" option in upgrading condition, i.e., do not use "Upgrade Now" option.

Your environment

  • CPython versions tested on: 3.11.0b5 (and any earlier prerelease of 3.11.0 iirc)
  • Operating system and architecture: Windows 11 build 22621.436 (22H2 Insider Build), ARM64 (Surface Pro X)
    Encountered same issue before switching to an Windows Insider build with earlier beta version of Python, so this doesn't seem related to me using Windows Insider build.

Activity

  1. zooba commented on Aug 3, 2022

    @zooba
    Member

    Thanks for the report! I'll check it out

  2. added a commit that references this issue on Aug 4, 2022
  3. zooba commented on Aug 4, 2022

    @zooba
    Member

    Phew, that was an interesting one. Along with the somewhat obvious registry issue (because "not x64" doesn't mean "x86" anymore), it seems Wix Toolset has changed the order of its bundle and package detection events, which broke some of the launcher detection. They're all related enough that I did them together.

    This should work fine in the next release, it doesn't depend on changing anything in existing installs.

  4. added a commit that references this issue on Aug 4, 2022
  5. added 2 commits that reference this issue on Aug 4, 2022
  6. added a commit that references this issue on Aug 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions