x.py expects python3.exe on Windows

[Kixiron]

Seems to be the root cause of #72523, @RDambrosio016 also encountered a similar (but less dramatic) issue. On windows it seems that x.py expects an executable of python3 to be named exactly python3.exe and will encounter varying errors while spawning internal python processes when these conditions are not met

[RDambrosio016]

Yes, x.py does not work if you install python then use py, it only works if you use python3.

[steveklabnik]

Very odd; I use "python x.py" on Windows just fine.

rust on 📙 master via 🐍 v3.8.3 via 🦀 v1.44.1
❯ python --version
Python 3.8.3
rust on 📙 master via 🐍 v3.8.3 via 🦀 v1.44.1
❯ python x.py build
Updating only changed submodules
Submodules updated in 0.14 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 3.81s
Building stage0 std artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
    Finished release [optimized] target(s) in 0.82s
Copying stage0 std from stage0 (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc / x86_64-pc-windows-msvc)
Building stage0 compiler artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)

[RalfJung]

Is this the Windows version of #75034?

[mati865]

@RalfJung it's entirely different. This issue is some kind of user environment issue.

There is no python3.exe in official Python packages for Windows:

$ unzip -l python-3.8.5-embed-amd64.zip
Archive:  python-3.8.5-embed-amd64.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   100424  2020-07-20 16:03   python.exe
    98888  2020-07-20 16:03   pythonw.exe
  4209224  2020-07-20 16:03   python38.dll
    58952  2020-07-20 16:03   python3.dll
    89880  2020-07-20 16:03   vcruntime140.dll
    44312  2020-07-20 16:03   vcruntime140_1.dll
    31453  2020-07-20 16:03   LICENSE.txt
   189000  2020-07-20 16:03   pyexpat.pyd
    26696  2020-07-20 16:03   select.pyd
  1096264  2020-07-20 16:03   unicodedata.pyd
    29256  2020-07-20 16:03   winsound.pyd
    63560  2020-07-20 16:03   _asyncio.pyd
    86088  2020-07-20 16:03   _bz2.pyd
   126024  2020-07-20 16:03   _ctypes.pyd
   266824  2020-07-20 16:03   _decimal.pyd
   177224  2020-07-20 16:03   _elementtree.pyd
    46152  2020-07-20 16:03   _hashlib.pyd
   162376  2020-07-20 16:03   _lzma.pyd
    38984  2020-07-20 16:03   _msi.pyd
    29256  2020-07-20 16:03   _multiprocessing.pyd
    45640  2020-07-20 16:03   _overlapped.pyd
    28232  2020-07-20 16:03   _queue.pyd
    78920  2020-07-20 16:03   _socket.pyd
    87624  2020-07-20 16:03   _sqlite3.pyd
   153672  2020-07-20 16:03   _ssl.pyd
  3399200  2020-07-20 16:03   libcrypto-1_1.dll
    32792  2020-07-20 16:03   libffi-7.dll
   689184  2020-07-20 16:03   libssl-1_1.dll
  1475656  2020-07-20 16:03   sqlite3.dll
  2458947  2020-07-20 16:04   python38.zip
       79  2020-07-20 16:04   python38._pth
   533307  2020-07-20 16:03   python.cat
---------                     -------
 15954090                     32 files

Also tried official Python installed in Windows virtual machine and there is no python3.exe whatsoever.
MinGW Python 3 installed with MSYS2 provides both python.exe and python3.exe.

[RalfJung]

Oh I see. But if python3 is the standard name on Linux for the Python 3 executable, then why do they use a different name on Windows...?

[mati865]

🤷‍♂️ I'm not involved with the upstream Python 😄

[RalfJung]

IMO it would be good if someone who actually uses Python on Windows could bring this to their attention in their bugtracker. :)

[ollie27]

FWIW I've been running py x.py on Windows for ages with on issues. I don't have any python3.exe. I'm also not running in an MSYS2 environment.

As far as I can tell x.py doesn't care what your python binary happens to be called. I've just tested and even pypy3.exe works.

@Kixiron or @RDambrosio016 could you provide instructions for reproducing whatever issue you are having?

[jyn514]

There is now a tool called x which will find the appropriate version of python and run it: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#running-xpy-slightly-more-conveniently. Would that meet this use case?

[jyn514]

I'm going to close this since no one's been able to reproduce the issue. Feel free to reopen if you can replicate this.