Script entry point for console script set to "pythonw" if pip is run with pythonw

[ThimoNeubauer]

Problem description

Note that I've observed the following problem with any Python package containing a "console_script" entry point. For the reproducer I've randomly chosen pipdeptree

Let's start with the non-broken case:

PS E:\temp> C:\Python311\python.exe -m venv Visible
PS E:\temp> .\Visible\Scripts\python -m pip install pipdeptree
Collecting pipdeptree
  ... blah blah ...
Installing collected packages: pipdeptree
Successfully installed pipdeptree-2.13.0
PS E:\temp> .\Visible\Scripts\pipdeptree.exe --help
usage: pipdeptree [-h] [-v] [-w [{silence,suppress,fail}]] [-r] [--python PYTHON] [-p P] [-e P] [-a] [-l | -u] [-f] [--encoding E] [-d D] [-j | --json-tree | --mermaid | --graph-output FMT]

Dependency tree of the installed python packages
 ... more stuff ...

When I do the same with pythonw the installed script doesn't show anything:

PS E:\temp> C:\Python311\python.exe -m venv Hidden
PS E:\temp> .\Hidden\Scripts\pythonw -m pip install pipdeptree
PS E:\temp> .\Hidden\Scripts\pipdeptree.exe --help
PS E:\temp>

Looking into the generated .exes with a WSL shell I can also see the problem:

tnr1@LP15-TNR1-CST:/mnt/e/temp$ strings Hidden/Scripts/pipdeptree.exe | grep python
#!E:\temp\Hidden\Scripts\pythonw.exe
tnr1@LP15-TNR1-CST:/mnt/e/temp$ strings Visible/Scripts/pipdeptree.exe | grep python
#!E:\temp\Visible\Scripts\python.exe
tnr1@LP15-TNR1-CST:/mnt/e/temp$

Is seems as if pip (or some other layer?) uses sys.executable instead of "python" for the console scripts. Version info:

PS E:\temp> .\Visible\Scripts\pip --version
pip 23.2.1 from E:\temp\Visible\Lib\site-packages\pip (python 3.11)

Why would this problem be relevant? I constructed an internal tool to keep virtual environments up-to-date, essentially calling pip install --upgrade. What we want/need is that this updating also takes place on Windows machines if the user isn't currently logged in. Starting a scheduled task with user credentials is easy but then we need to call "pythonw": "python" fails because it cannot show the console windows. What we noticed now is that scripts of packages that were upgraded by this automatic tasks suddenly didn't show console output anymore