-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registry keys for Windows Store package have wrong executable #81915
Comments
The next update to Windows will prevent launching executables from within the package install folder, and require you to launch from the user's local symlink to the executable (see bpo-37369). Currently, the only value we can put into the registry when installing via the Store package points directly to the package install. There is no way to point at the local symlink. I'm working with the Windows team to find either a fix or a workaround, but right now anyone who updates to preview Windows (or gets the update when it releases at the end of the year) will not be able to launch Python through tools that look in the registry. |
So far we've figured out that using the full installed path will work fine (by design) if you have enabled the matching alias. So essentially, if Python is on your PATH, you can also launch it using the full path. I'm trying to convince them that it should only have to be installed for the current user. If they agree with that, we might get this fixed properly and then there's nothing to do here. |
It looks like the best solution here may be to rename the bundled executables to "python3.8.exe" etc. rather than "python.exe". We will still keep the "python.exe" alias, and sys.executable won't change (it'll still point to the stable alias), but by having the "core" executable be named differently between Python versions it'll fix a couple of minor issues. Most importantly here, because the registry path would then point at "python3.8.exe" rather than "python.exe", it becomes more likely that the global alias will remain enabled and so launching via the registry path will work. The downside is that apps that use "$InstallPath\python.exe" rather than "$ExecutablePath" will not work. But the ExecutablePath value has been present for a while now, and PEP-514 specifies it as preferred when available, so I think that's okay. We can also include a plain "python[w].exe" in the installation, but that'll only be useful for subprocess.run("python") from the same version - it won't be executable at all from outside the app package. (None of this affects the regular installer, FWIW. That'll still be plain "python.exe".) Anyone have any thoughts or concerns? |
Going to leave this open in commit review for now. I believe this will significantly improve the reliability, but depending on which Windows bugs people run into there may still be more things we can do. |
Here's an example of someone hitting this issue: https://stackoverflow.com/q/56974927 |
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
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: