Windows py.exe launcher interacts badly with Windows store python.exe shim

[ben-spiller]

BPO	40687
Nosy	@pfmoore, @tjguk, @zware, @zooba, @ben-spiller

^{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:

assignee = None
closed_at = None
created_at = <Date 2020-05-19.17:20:47.731>
labels = ['3.10', 'type-bug', '3.8', '3.9', 'OS-windows']
title = 'Windows py.exe launcher interacts badly with Windows store python.exe shim'
updated_at = <Date 2020-05-19.17:44:01.993>
user = 'https://github.com/ben-spiller'

bugs.python.org fields:

activity = <Date 2020-05-19.17:44:01.993>
actor = 'steve.dower'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2020-05-19.17:20:47.731>
creator = 'benspiller'
dependencies = []
files = []
hgrepos = []
issue_num = 40687
keywords = []
message_count = 2.0
messages = ['369379', '369380']
nosy_count = 5.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'steve.dower', 'benspiller']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue40687'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[ben-spiller]

The py.exe launcher doc states "If no relevant options are set, the commands python and python2 will use the latest Python 2.x version installed" ... which was indeed working reliably until Microsoft added their weird python.exe shim (which either terminates with no output or brings up the Microsoft Store page) as part of https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/

Now, I find scripts that start with "#!/usr/bin/env python" cause py.exe to run the Windows python.exe shim which confusingly terminates with no output (unless run with no arguments).

I think to stop lots of developers banging theirs heads against this brick wall, py.exe should include some logic to ignore the C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe shim, since for someone with py.exe installed, running that is _never_ what you'd want. (or alternatively, work with Microsoft to get this decision reversed, but that may be harder!)

Lots of people are hitting this e.g. https://superuser.com/questions/1437590/typing-python-on-windows-10-version-1903-command-prompt-opens-microsoft-stor , https://stackoverflow.com/questions/57485491/python-python3-executes-in-command-prompt-but-does-not-run-correctly

Here's the output:

py myscript.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\XXX\AppData\Local\py.ini' non-existent
Using global configuration file 'C:\WINDOWS\py.ini'
Called with command line: apama-build\build.py -h
maybe_handle_shebang: read 256 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python
searching PATH for python executable
Python on path: C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe
located python on PATH: C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe
run_child: about to run 'C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe myscript.py'
child process exit code: 9009

py -0
Installed Pythons found by py Launcher for Windows
-3.8-64 *
-3.7-64
-3.6-64
-2.7-64

(nb: was surprising that it didn't run any of those installed versions!)

[zooba]

If someone remembers where the other "shebangs on Windows don't make sense" issue is, I think we can close this one in favour of that.

Though it's also an important point for bpo-40667 - if "python.exe" becomes the launcher, then this will get stuck in an infinite loop (and process memory exhaustion is the worst kind of hang on Windows).

[zooba]

This was recently fixed - the py.exe launcher will no longer launch the redirector stub.