Change:
# If this is python2, check if python3 is available and re-execute with that # interpreter. <ins> # # `./x.py` would not normally benefit from this because the bash above tries # python3 before 2, but this matters if someone ran `python x.py` and their # system's `python` is python2. </ins> if sys.version_info.major < 3: try: <del> # On Windows, `py -3` sometimes works. # Try this first, because 'python3' sometimes tries to launch the app # store on Windows </del> os.execvp("py", ["py", "-3"] + sys.argv) except OSError: try:

Discussion:
Since Ubuntu 20.04, the name without package being installed. The build scripts should point to instead.
Or if the scripts have been python3-ready, it should probably instead point to ?
I guess mistakenly, when landing the python 3 preparation patch I assumed that python would be symlinked to the preferred python installation on most systems, but it seems like that's not proven out in practice. Do we have some sense whether there is some executable we can put in the x.py script shebang which would mostly just work on most systems? If python3 will do the trick, I'm down for approving a PR switching us over to that.
I'm fairly sure that calling should work.
Do you mean in general? Or specifically to fix it not working in the common case? I agree that doing so fixes the bug but I'm not clear on whether that's the right approach. It's surprising to me that we're forced to recommend python3 over python2.7, basically.
For what it's worth, python2.7 since January 1st, 2020. So I would argue that it's fine to recommend python3 over python2.7 now.
in this specific issue AFAIK user can choose which Python to use by calling or instead of even if doesn't exist. The only general solution I can think of is creating that will probe for available Python versions.
Yes, I'm aware, but I believe that many distros still ship and use python 2. I think x.sh seems like overdoing it, and I do want the common case to work. With that in mind, I'll file a PR later today switching to python 3 as the default (though we will continue to support python 2.7).
Python 2 was supposed to be (as announced in 2008), but people still supporting it led to it being extended to 2020. I don't think it's a good idea to support it any further, is there any reason to do so?
This is not the place to discuss it -- if you want further details than this comment, please ask on Zulip etc. But I personally do not believe that it is Rust compiler's build systems place to force people to upgrade unrelated software; the intent of the build system is to work as well as it can on as wide a range of base systems as possible, including those that only have python 2.

Filed for the fix to this issue.
That PR got closed, if I understood correctly due to Windows compatibility issues. Looks like there is no python binary name that actually works across platforms anymore? Windows doesn't have and some Linux distros don't have ? What a mess.
maybe we should file this to python X)
I think is a duplicate of this.
There is now a tool called which will find the appropriate version of python and run it: https://rustc-dev- Would that meet this use case?
I've updated to explicitly detail that users need a command available on their system, otherwise the script will not run directly using the format. I've also details on how to work around the issue.
Such a script would be ideal, except using specifically as part of the build instructions adds rust as a requirement to run the bootstrapper, which might not be ideal.
To be precise, it may have . Basically there are two installers, the classic one available from and the modern one available through the Windows Store. The latter one has whereas the former requires you to do to select python 3. So to sum up the three standard options are: python isn't installed is in the is in the
does that mean that " is in the PATH" is uncommon? Would it be better for Windows users if we switched to in the shebang?
Ah, (without the ) should be in the PATH, unless that option wasn't selected when using the installer. It could be either version 2 or 3 depending which are installed and it what order.
(hoisting from the other issue, closed in favor of this one) macOS Monterey 12.3 was released today. The include: The tool used for the development process of the compiler starts with the line On macOS Monterey 12.3, running results in It would probably be the time to make the script require Python 3, with This means that in addition to various linux distributions, macOS joins the club of not being available as a name. It was also mentioned that the main reason for not having changed to was Windows not supporting that name. . While it is possible to work around this (e.g. by editing the local x.py script to mention , or creating a symlink, or other), this is an annoying papercut and it will be hitting more and more people.

Currently at least_ all Ubuntu users, all macOS users on 12.3, more - need to add a workaround manually on their system. Considering this issue has been open since 2020, what are the possible actions / next steps we could take to fix this properly for everyone?
I think the likely immediate next step if someone would like to make progress on this is to do a survey across at least tier-1 platforms (macOS, Windows, Linux, in no particular order), with likely some more variants of each (by install method, etc) in terms of the likely binaries available in a common PATH, and ease of getting other binaries/symlinks (e.g., python-is-python3 and similar packages). A comment with that information would let us make an informed decision as to: Is there a clear majority around some name? Or, is there a platform that we could push to change/add an executable that would bring us to a clear majority? To be clear, this is not really about python 2 vs. python 3; we support both and I don't expect that to change in the immediate future. My recollection (but hard data would be good) is that just picking a python version is insufficient to guarantee a particular executable names availability, so I don't think making any choices there actually would help us. If it would, that's fine too. (Edit: Yes, in the long run is likely at least a start to the future, though I'm not sure we'll ever fully drop x.py -- or some similar tooling.)
Hoisting from Zulip: On my Windows 11 machine, if i run in either Powershell or CMD, the Windows Store automatically opens to the official Python 3.10 software page, published by Python Software Foundation. After I click the Get button to install it, in both Powershell and CMD, running results in . After the installation, if I write a small file and run in Powershell or in CMD, on first run I get the modal for "what do you want to use to open this file", if i select Python 3.10, it will launch a new window where the output is shown. So at least on windows 11 with the python3 installed directly from windows store (as it automatically suggests if you try to run python3) the shebang of seems to work perfectly fine!

I then uninstalled the version from the Windows Store, and installed using the newest installer from . I installed with the default options, without selecting the "add python 3.10 to PATH" option, as it was unselected by default. Even with this installation, running the abovementioned works in Powershell and in CMD, with the shebang set to . Conversely, if I set the shebang to , then it actually fails with an error of - as in, the current shebang is broken even on Windows. It has also been mentioned that some people use the wrapper. The documentation of says the following: <blockquoteLines If the first line of a script file starts with #!, it is known as a “shebang” line. Linux and other Unix like operating systems have native support for such lines and they are commonly used on such systems to indicate how a script should be executed. This launcher allows the same facilities to be used with Python scripts on Windows and the examples above demonstrate their use. To allow shebang lines in Python scripts to be portable between Unix and Windows, this launcher supports a number of ‘virtual’ commands to specify which interpreter to use. The supported virtual commands are: /usr/bin/env python /usr/bin/python /usr/local/bin/python python For example, if the first line of your script starts with #! /usr/bin/python The default Python will be located and used. As many Python scripts written to work on Unix will already have this line, you should find these scripts can be used by the launcher without modification. If you are writing a new script on Windows which you hope will be useful on Unix, you should use one of the shebang lines starting with /usr. Any of the above virtual commands can be suffixed with an explicit version (either just the major version, or the major and minor version). Furthermore the 32-bit version can be requested by adding “-32” after the minor version. I.e. /usr/bin/python2.7-32 will request usage of the 32-bit python 2.7. </blockquoteNote especially: "Any of the above virtual commands can be suffixed with an explicit version (either just the major version, or the major and minor version)" I tried using this wrapper too, and I get the same behavior: in both Powershell and CMD with shebang of works, doesn't.

Based on this, it looks to me like the shebang of should work even on Windows, both when installed via Windows Store as well as when installed via the official Python installer. It even looks like the current shebang of is broken even on Windows, which has previously been held as the blocker for switching to . I would be more than happy to create a tiny PR for this, if allowed!
I've proposed a possible solution in . Please take a look.