Python 3.10 installed from the Microsoft Store does not add scripts to path

[avalonv]

Bug report

After installing Python 3.10 from the Microsoft Store, I tried to install a package and was hit with the following warning:

WARNING: The script reCBZ.exe is installed in 'C:\Users\username\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\Scripts' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

Which prevents me from calling the script directly, I have to use python -m reCBZ

Manually adding the path works, however I would have expected the Python installation from the Microsoft store to have done this automatically.

Steps to reproduce:

1. Install Python 3.10 from Microsoft Store
2. Pip install a python package which provides a script 'myscript' (ex reCBZ)
3. Try to call the script with 'myscript'

Expected results:

1. local-packages is in PATH
2. Script runs

Actual results:

1. local-packages is not in PATH
2. Windows complains about 'myscript' not being a recognized command

I'm normally a Linux gal so I deeply apologize if this is a misunderstanding from my part -_-

Your environment

• CPython versions tested on: Python 3.10 (Microsoft store)
• Operating system and architecture: Windows 10.0.19043 Build 19043, x86-64

[eryksun]

I don't know if it's possible for an app installation to modify user environment variables. Probably not. But the store app is at least allowed to modify the user "Path" value in "HKCU\Environment". pip could go a step further to add the scripts directory to PATH, if the user consents to this, and broadcast a WM_SETTINGCHANGE "Evironment" message to top-level windows. The new PATH won't be available in the current shell, however. A new terminal window or tab would have to be opened.

[cbrnr]

I think adding the scripts to the user path (with whatever method works for store apps) would be truly appreciated. I'm getting bug reports for my app because people are using the Microsoft Store to install Python, and right now I recommend that they don't and use the official installer from python.org instead.

[PySimpleGUI]

I'm running into this problem. All of my applications are GUI programs and rely on users accessing the EXE file that's on the scripts folder. I was able to modify the registry, but it doesn't show up in the environment even after opening a new command prompt. I'm guessing it requires logging the user out.

This is the bit of code I used to add to the registry.

import winreg

def add_to_path(path_to_add):
    with winreg.OpenKey(winreg.HKEY_CURRENT_USER, 'Environment', 0, winreg.KEY_ALL_ACCESS) as key:
        current_path = winreg.QueryValueEx(key, 'Path')[0]
        new_path = current_path + ';' + path_to_add
        winreg.SetValueEx(key, 'Path', 0, winreg.REG_EXPAND_SZ, new_path)

I'm not feeling very comfortable, however, modifying the users path in their registry from my setup.py file.

Is this going to be fixed at some point?

[zooba]

I'm not feeling very comfortable, however, modifying the users path in their registry from my setup.py file.

Just as we're not comfortable modifying the user's path in their registry either.

Is this going to be fixed at some point?

Only if Microsoft provide a way for an installer package to set a user-specific key to a user-specific value. Currently, all we can set on install are global commands. As the "Scripts" folder is not global, and we don't know what commands are going in there at compile time, we can't do it from the installer.

It would theoretically be possible to make the runtime do it, but we don't have any way to uninstall it. A script like yours is the right idea, though it would need to be significantly more robust for us to consider putting it in the core runtime or making it automatic.

The best workaround we've got right now is that pip will print out the path to Scripts if it installs an entry point there and finds that it's not on PATH. Provided you aren't generating lots of other output, that message should be very visible to users.

The other best workaround, is to use a virtual environment. The scripts folder for that will be put on PATH when activated, which overall is a much more reliable model than modifying global PATH.

I was able to modify the registry, but it doesn't show up in the environment even after opening a new command prompt. I'm guessing it requires logging the user out.

You need to broadcast WM_SETTINGCHANGE to all windows after changing the registry, which will update Explorer so that the next time you launch a console it has the right environment. But logging out is also an acceptable way to do it.