Turns out Python uses the basename of the calling executable to
decide which launcher in the venv it uses to call pip with.
This means we have to copy all launchers we ship.
Use the non versioned launchers as src so the rewrite logic in venv
copies the venvlauncher variants.
Fixes#7227
The venv code for the uninstalled case depends on various hacks only
present in the Windows code paths, so instead of using the unix ones
patch the windows ones.
We now create a venvlauncher.exe in the build dir which gets copied
to the venv package during install, and when run uninstalled copies
it to the created venvs. This is mroe in line with what the msvc build
does.
We aren't currently compiling the venvlauncher as part of python with
gcc. Previous patches in PR #5625 removed the venvlauncher redirector
by skipping "nt" platform portions in the venv module.
Although the previous patches worked to fix venv, it left us with key
venvlauncher files missing that were expected to be present in Windows.
In issue #7014, tox and other tools that depend on virtualenv were
unable to run. For example, there was issues with no such file or
directory errors:
'mingw64/lib/python3.8/venv/scripts/nt/python.exe'
This fixes these issues by removing some of the previous patches in venv
and copying python.exe and pythonw.exe to the locations where the
venvlauncher redirect files are expected. A future solution may be to
try to compile venvlauncher using gcc.
* remove commented out stuff
* remove mtime changes, handled by "make rebuild-x" in newer Python
* remove patch for changing the exe names so it happens for all tools in one place
