[issue41327] Windows Store "stub" Python executables give confusing behaviour

Eryk Sun added the comment: > This is exactly what it does. The fact that it is SUBSYSTEM:WINDOWS Sorry, I neglected to check: C:\>python3 script.py 2>&1 | more Python was not found but can be installed from the Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Steve Dower added the comment: > Windows 10 has a "Feedback Hub" to report problems and search for existing > feedback that's similar. This is the correct channel, but ultimately the "real" issue tracker is private, so all you'll ever get is "not finished yet" that suddenly becomes

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Eryk Sun added the comment: > there would still be value in having a known reporting channel Windows 10 has a "Feedback Hub" to report problems and search for existing feedback that's similar. You could report a problem with the "AppInstaller" app. In this case, the app execution alias

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Paul Moore added the comment: Understood that these would be duplicates, and I certainly don't want to put more pressure on you, but I think there would still be value in having a known reporting channel for people to say "I am also affected by this": * MS Developers get a more objective

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Steve Dower added the comment: It's already gone through the correct channels, so any other submissions will be duped by the triagers. The best person to post at is me, but I've suffered enough for it :) I'm pushing. -- ___ Python tracker

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Tzu-ping Chung added the comment: What would be the best channel to raise this issue to the Windows team from the outside? It does not need to be a spam campaign, but it’d be nice if we could direct the affected users somewhere instead of pypa/packaging-problems and various issue trackers,

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Steve Dower added the comment: It already returns a non-zero exit code (should be (IIRC) 9009 to match the built-in cmd.exe result), and I've been trying to get the message added for at least a year now. Unfortunately, I can only push it so far before it has to work through the Windows

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Tzu-ping Chung added the comment: FWIW, I tweeted about this a while ago (January) and IIRC Steve said there’s plan to change that. https://twitter.com/uranusjr/status/1212450480917340160 -- nosy: +uranusjr ___ Python tracker

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Paul Moore added the comment: I thought that might be the answer. But does anyone know where I can repost this as an issue against the Store distribution? I'm happy to report there if I can find out how... Hopefully Steve can point me in the right direction. --

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Brett Cannon added the comment: Closing as "third-party" as those stubs are controlled by Microsoft Windows and has nothing to do with us as a project beyond that they install the Windows Store copy that Steve uploads (although this is all feedback to Steve who has connections on the

[issue41327] Windows Store "stub" Python executables give confusing behaviour

Paul Moore added the comment: See, for example, https://github.com/pypa/packaging-problems/issues/379 as an illustration of the user (and project maintainer!) confusion this causes. -- ___ Python tracker

[issue41327] Windows Store "stub" Python executables give confusing behaviour

New submission from Paul Moore : First of all, I do know that this is an issue with the Windows Store distribution, rather than the python.org one. But (a) I don't know where to report a bug against the Store implementation except here, and (b) it's arguably a case of the Windows