About .exe wrappers created by frontends when installing wheels on Windows?

Packaging
7

Thanks a lot. All this is very interesting for me, who discover Windows and .exe wrappers.

To summarize the answers:

Having our own entry point is fine but it might not be necessary since

  1. The effect of PYTHONLEGACYWINDOWSSTDIO can be obtained from Python

  2. long paths should be activated when using console-script entry point since the general wrapper .exe created by distlib (so pip and pipx) launches python.exe in a subprocess, and python.exe has the correct manifest.

We will be able to try that for Mercurial.

Side note

I still don’t understand how these .exe wrappers work on Windows and how they are used by Python. I see that they can be created without any compiler installed, which is counter intuitive for me. I don’t understand if they contain the absolute path towards the Python executable to be used. Can they just be copied in another location? Is the .exe wrapper created by pipx in $HOME/.local/bin just a copy of the .exe wrapper in the venv?

Can we somehow read the information in a .exe wrapper to know what is called (similar to head $(which black) on Unix)?

It seems to me that venv also uses a .exe wrapper for python.exe in a Python environment (the two files do not have the same size).

I’d like to understand these things in particular because of a performance issue I encounter on a Windows computer where I observe a delay of approximately 0.5 second before starting applications with .exe wrappers (see Slow startup on Windows for virtual environments - #17 by paugier).

1 Like