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

[Eryk Sun]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

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 
"finished" (and generally that's updated on release, not on commit, because 
we've found that users get confused when something is claimed to be fixed but 
they're still seeing the issue).

> IMO, the installer-redirector in this case should be a console application 
> that prints a message to stdout to inform the user that it's opening the 
> store to install Python.

This is exactly what it does. The fact that it is SUBSYSTEM:WINDOWS instead of 
CONSOLE is what I'm trying to get fixed. It's not complicated, it's just not 
something that anyone can force through besides the team that owns the code, 
and they own a lot of other things that need fixing as well (and the release 
schedule doesn't allow for "just one little fix"). Shipping an OS is *hard* ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eryk Sun]

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 targets 
"AppInstallerPythonRedirector.exe". This is a GUI program, so CMD won't wait on 
it and set %errorlevel% if run from an interactive prompt -- not unless one 
uses `start /w` to force it to wait. (Sidebar: CMD determines that it's a GUI 
program by querying the PEB address and reading the process PEB via 
ReadProcessMemory... hack-o-rama.) 

IMO, the installer-redirector in this case should be a console application that 
prints a message to stdout to inform the user that it's opening the store to 
install Python. If it fails, it should print an error message to stderr and 
return a non-zero exit status.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Moore]

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 feel for the scale of the issue.
* Users who report the issue can track progress (they will presumably get told 
*what* their report is a duplicate of, and can follow the underlying issue).
* Python package developers have something definite that they can offer to 
users.

My suspicion here is that MS simply doesn't have a user-visible support channel 
for the Store Python stubs, which is why we've ended up discussing this here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tzu-ping Chung]

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, where the Windows team wouldn’t see.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

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 team's process, and then there's nobody to push it along. All that 
could really be done from outside is to organise a "why don't you fix the dev 
experience" spam campaign, but I'm not going to condone that ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tzu-ping Chung]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Moore]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brett Cannon]

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 Windows team).

And I will say I believe there are shims on some Linux distros like Ubuntu for 
things like venv, pip, etc. which are not included in-box which people 
typically expect to be there.

--
nosy: +brett.cannon
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Moore]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Moore]

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 implementation "stealing" the Python command, so 
worth flagging against core Python.

The problem is that Windows 10 installs `python` and `python3` executables by 
default, which open the Windows Store offering to install Python. That's not a 
bad thing - it's nice to have Python available with the OS! Although (see 
below) hijacking the `python` and `python3` commands for this purpose has some 
problems.

But those stubs silently do nothing when run with command line arguments, and 
because the python.org distribution doesn't put Python on PATH by default, 
users end up with the stubs available even if they install python.org Python.

We're getting a lot of bug reports from users as a result of this, when they 
follow standard instructions like "execute `python -m pip`". With the stub on 
the path, this silently does nothing, even though the user has installed 
Python. This is a very bad user experience, and not one that projects like pip 
can do anything to alleviate, other than having extremely convoluted "how to 
run pip" commands:

"""
To run pip, type `python -m pip` if you're on Unix, and `py -m pip` on Windows. 
Unless you're using the Windows Store version when you should do `python -m 
pip` on Windows too. Or on Unix when you might need to do `python3 -m pip`. 
Or...
"""

I don't have a good answer to this issue. Maybe the Windows Store stubs could 
detect core Python and do something better if it's installed? Maybe the stubs 
should print an explanatory message if run with command line arguments? Maybe 
Store Python should be available on Windows via some less error-prone mechanism?

I'm pretty sure if a Linux distribution shipped a `python` command that didn't 
run Python the way users expected, there would be complaints. After all, we 
have PEP 394 that explicitly states how we expect Unix systems to work. Maybe 
we need something similar for Windows?

--
assignee: steve.dower
components: Windows
messages: 373845
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Store "stub" Python executables give confusing behaviour
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com