Install manager breaks running scripts from Command Prompt via Windows file associations

[alabuzhev]

Install source and version

• Installed from the Windows Store
• Installed with the MSIX from python.org
• Installed with the MSI from python.org
• Installed with winget install 9NQ7512CXL7T

Version:
25.0

Describe the bug
When Python install manager is installed, Windows file associations for python scripts do not work as expected when scripts are invoked from Command Prompt (cmd.exe): the interpreter starts in a new console window instead of the same one.

To Reproduce
Steps to reproduce the behavior:

1. Install Python install manager
2. Run it, let it download Python
3. Create a simple script that prints something:

test.py

print("Hello, World")

4. Open Windows Command Prompt (Win+R, cmd, Enter)
5. Go to the directory with the script above, e.g. cd <your_path>
6. Run the script directly, e.g. test.py
   Note: NOT python test.py or py test.py

Expected behavior
The interpreter runs in the same console.
The text is printed into the same console.
The text is visible to the user after the interpreter exits.

Actual behavior
A completely new console window opens, with something like C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_25.0.240.0_x64__3847v3x7pw1km\python.exe in the title.
The text is printed into that new console.
The text is not visible to the user after the interpreter exits.

Additional context
It used to work as expected with Python Launcher.

[zooba]

This is partly due to Windows changing (or not changing, to properly support their newer style file associations). I believe there's been no change to PowerShell's behaviour, which is what we'd (and they'd) consider the default now - cmd.exe is practically retired.

For us to fix this upstream, we'd have to stop distributing the MSIX entirely, which leads to other regressions that we think are worse than this one. Such as missing context menus, admin-only installation, unmanageable global shortcuts, insufficiently registered default applications, and automatic installer updates.

Some workarounds if this is critical functionality for you (besides just using py ... as you mentioned):

• install the MSI instead of the MSIX
• create a new file association to "%LocalAppData%\Python\bin\python.exe" "%1" %*
• create a test.bat that contains @py "%~dpn0.py" %* (will launch <batch file name>.py with all args)

[alabuzhev]

I believe there's been no change to PowerShell's behaviour

PowerShell is affected as well:

(and every other console app that uses ShellExecute(Ex) to run Python scripts)

For us to fix this upstream, we'd have to stop distributing the MSIX entirely

Supposedly there are other ways.
For example, you probably could free this new console and attach to the parent process manually before running the real Python.

missing context menus, admin-only installation, unmanageable global shortcuts, insufficiently registered default applications, and automatic installer updates

Such horrors. I wonder how the rest of the world still manages without MSIX.

[zooba]

and every other console app that uses ShellExecute(Ex) to run Python scripts

Which just reinforces that it's an OS change.

Supposedly there are other ways ...

Unfortunately, we don't have a way to know which console we were started from, though it's probably possible (at the cost of 2-3x slower startup time) to detect this case and do something. It's just not obvious enough what that something would be, and whether it's an improvement for everyone else.

I wonder how the rest of the world still manages without MSIX

Buggy and vulnerable installers, just like we had 🤷‍♂️ . As a volunteer organisation who pay exactly zero people to care about installers (at this low level), we've got to balance the needs of our entire user base and make tradeoffs. Anyone is welcome to make their own installer for Python for specialised cases. We don't insist on having a monopoly over it.

[alabuzhev]

we don't have a way to know

It should be possible to figure out everything, but I suppose you're not really interested.
Which is understandable, it's extra work and extra risk.

Anyone is welcome to make their own installer for Python for specialised cases.

Unfortunately, this is not what people usually do.
Usually they download stuff from python.org, notice that something doesn't work and create bugreports like "your app cannot run a simple Python script properly, do something", and you can't really do anything.

Thanks anyway.

[quetschke]

Well, it seems like it is not fixable, but it is still a regression. Frankly, I spent some time looking for solutions on the internet, but no response was actually helpful.

At the least, the new behavior, together with the strong advice to prepend py to scripts should be mentioned on the python install manger page and the troubleshooting section page of the documentation.

The new behavior breaks a lot of legacy code that calls python scripts from .cmd or .ps1 files. It is important that people are made aware of the new behavior.

[zooba]

Frankly, I spent some time looking for solutions on the internet, but no response was actually helpful.

It's been available less than a month, so this is going to be the only place with any real information (but hopefully it stays the best place).

Adding it to the troubleshooting page makes perfect sense. That requires an issue and PR on python/cpython.

The download page text is already packed full of too much information and I expect very few people are reading it as it is - adding fairly obscure tidbits like this one (sorry, but it is not actually a core feature for most users!) just makes it less likely anyone will read the page.

The recommended use is still and always has been to use py or to activate a virtual environment. The possibility of relying on the Windows Shell to resolve it was always very context dependent (especially since Windows changes in each release how associations are updated and whether there is blocking UI involved), and trying to rely on it in scripts was never going to be reliable. If this is the first time it's broken for you, you've done very well!

[pfmoore]

PowerShell is affected as well

It works for me in Powershell, so it's definitely not a universal issue. Do you have .PY in your PATHEXT environment variable? I have:

❯ $env:PATHEXT
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYZ;.PYW;.PYZW;.CPL

In many ways I agree that there should be a way to reliably write "executable scripts" in whatever language you wish, and this should be supported at the OS level, so it works in all shells, and wherever processes can be started. But that's an OS feature request, and the history clearly indicates that it's not something that Microsoft considers a priority - if it works, there are all sorts of edge cases and exceptions, and they will happily break it without warning. I therefore reluctantly agree with @zooba that this isn't something that we can fix here.

[alabuzhev]

sorry, but it is not actually a core feature for most users!

Running scripts from a shell is not a core feature?
It's absolutely fine to think so. But I humbly suggest to buckle up when this new approach is enforced.

Do you have .PY in your PATHEXT environment variable?

I don't. Added it, but it changed nothing.

this should be supported at the OS level

It is supported at the OS level.
The existence of the MSI package and the legacy installer confirms that.
If it doesn't work via MSIX (or whatever else Microsoft invented this week), it only means that MSIX is not necessarily the best tool for the job.

[zooba]

Running scripts from a shell is not a core feature?

Running scripts via a shell association is not a core feature, correct. That feature is for opening documents. Running a script via its executable absolutely is a core feature, and it works fine.

If it doesn't work via MSIX (or whatever else Microsoft invented this week), it only means that MSIX is not necessarily the best tool for the job.

MSIX is over a decade old, but yes, it still has some gaps. This one is recognised, but not necessarily considered critical.

MSI is retired and not getting any fixes at all, and Command Prompt is also not getting any significant development (or the dev team could do the same work they had to do for legacy file associations to make them behave the way you expect - yes, that took work, because it's not the default behaviour for a shell association). These technologies may be not be being removed from Windows, because that's how Windows operates, but they are not good choices for any new development these days.