Failed to call python after install python3.12 via python installer

[leidwang]

Bug report

Bug description:

Env: Win10-64 OS Python installer version: python3.12.0 How to reproduce the issue:

1. Download Windows installer (64-bit) from https://www.python.org/downloads/windows/
2. Install it via following command: python-3.12.0-amd64.exe /passive InstallAllUsers=1 AppendPath=1

After the installation finished, perform python in windows cmd.exe, then cmd will raise an popup to reminder us to install python from Microsoft Store,It means that the Windows OS does not have python installed.

Not sure if it is a bug for the installer or my step is wrong,could anyone help to check it?Thanks in advance!

CPython versions tested on:

3.12

Operating systems tested on:

Windows

[leidwang]

Add additional information about it.

If we try to use the python wrapper in C:\Windows\py.exe, we can perform py in cmd.exe, it will find our installed python. But I think this sounds most like a workaround, or it is expected behavior for Python usage?

Thanks.

[zooba]

I suspect you've hit the Windows bug that duplicates the PATH entry for WindowsApps. That entry ought to be in your user set of environment variables, but yours appears to be too high in the list. Moving that entry down to the bottom (roughly where it should be) ought to fix it.

If you dig into your registry settings you'll find that the path is listed differently in two different places. The per-user location is the one you want to keep.

[eryksun]

It seems that the installation failed to modify PATH. With the command line "python-3.12.0-amd64.exe /passive InstallAllUsers=1 AppendPath=1", Python 3.12 should have been installed in "C:\Program Files\Python312". Please verify that the interpreter was properly installed. For example:

> "C:\Program Files\Python312\python.exe" -V
Python 3.12.3

The latter directory as well as "C:\Program Files\Python312\Scripts" should have been appended to PATH. I just verified that this works as expected with a fresh installation of Python 3.12.3.

Note that the entry "C:\Python312" that's in your system PATH was not added by the installer.

[eryksun]

@zooba

I suspect you've hit the Windows bug that duplicates the PATH entry for WindowsApps

Note that the image shown is for the system PATH. (The "Path" variable in the bottom box that lists the system environment variables is highlighted with a grey background.) The entry "C:\Users\Administrator\..." does not belong there and should be removed. I'm surprised that a bug like that would make it into a release version of Windows 10.

That said, I think if they actually installed fresh via python-3.12.0-amd64.exe /passive InstallAllUsers=1 AppendPath=1, then something went wrong because "C:\Program Files\Python312\" and "C:\Program Files\Python312\Scripts\" should have been appended to the system PATH. Or if it was updating an existing installation of 3.12.0 in "C:\Python312", then it should have appended "C:\Python312\" and "C:\Python312\Scripts\" to the system PATH.

[leidwang]

Hi @zooba @eryksun

Thanks a lot for your quick reply.

Sorry to confuse you, I missed a parameter TargetDir="C:\Python312".So the complete command is like this python-3.12.0-amd64.exe /passive InstallAllUsers=1 AppendPath=1 TargetDir="C:\Python312"

[eryksun]

Sorry to confuse you, I missed a parameter TargetDir="C:\Python312".So the complete command is like this python-3.12.0-amd64.exe /passive InstallAllUsers=1 AppendPath=1 TargetDir="C:\Python312"

When I tested an update earlier, the installer updated the system PATH environment variable to append "C:\Python312\" and "C:\Python312\Scripts\", even if it already had an entry for "C:\Python312". Just now I can't reproduce that behavior, so it seems updating PATH is flaky when updating an existing installation. But it does appear to reliably append the base directory and scripts directory to the system PATH for a fresh all-users installation.

Running python should work fine from a new shell once you delete the "C:\Users\Administrator\AppData\..." entry from the system PATH. A user's "WindowsApps" directory does not belong there. You might want to add "C:\Python312\Scripts" to the system PATH to get the pip command if you prefer that for installing packages to the system site-packages. But you can use py -3.12 -m pip instead.

[leidwang]

Thanks all for your help and closing the issue.

[zooba]

The entry "C:\Users\Administrator..." does not belong there and should be removed. I'm surprised that a bug like that would make it into a release version of Windows 10.

I spent far too long investigating it, and I'm 99% sure the cause is a combination of another installer reading the HKLM PATH as REG_EXPAND_SZ, expanding the variables, modifying it, and writing it back as REG_SZ[^1], followed by a Windows update that migrates registry settings between two stages and fails to filter out the now expanded path. I couldn't prove it, unfortunately, and various teams I spoke to claimed they "never touch the registry", but every example I saw also had .NET Core installed and had gone through a Windows Update since that install (until this one, so I suspect something else has touched the registry PATH poorly).

Basically, nobody should be touching PATH through an installer, and hopefully one day [I will convince] Windows to give us better ways to manage global aliases.

[^1]: The .NET Core SDK installer was definitely doing this, and after getting it fixed the incidences have dropped dramatically, but no reason others couldn't do it too.

[leidwang]

The entry "C:\Users\Administrator..." does not belong there and should be removed. I'm surprised that a bug like that would make it into a release version of Windows 10.

I spent far too long investigating it, and I'm 99% sure the cause is a combination of another installer reading the HKLM PATH as REG_EXPAND_SZ, expanding the variables, modifying it, and writing it back as REG_SZ1, followed by a Windows update that migrates registry settings between two stages and fails to filter out the now expanded path. I couldn't prove it, unfortunately, and various teams I spoke to claimed they "never touch the registry", but every example I saw also had .NET Core installed and had gone through a Windows Update since that install (until this one, so I suspect something else has touched the registry PATH poorly).

Basically, nobody should be touching PATH through an installer, and hopefully one day [I will convince] Windows to give us better ways to manage global aliases.

Footnotes

1. The .NET Core SDK installer was definitely doing this, and after getting it fixed the incidences have dropped dramatically, but no reason others couldn't do it too. ↩

Thanks a lot for your precious time @zooba