Change:
/// Path to the python interpreter to use fn python(&self) -> &Path { <del> self.config.python.as_ref().unwrap() </del> <ins> if self.config.build.ends_with("apple-darwin") { // Force /usr/bin/python3 on macOS for LLDB tests because we're loading the // LLDB plugin's compiled module which only works with the system python // (namely not Homebrew-installed python) Path::new("/usr/bin/python3") } else { self.config .python .as_ref() .expect("python is required for running LLDB or rustdoc tests") } </ins> } /// Temporary directory that extended error information is emitted to.

Discussion:
python: python3: It sounds like python3 is strictly required for LLDB, so we should move this check from to , which will only require instead of both commands. cc label: +E-easy +E-mentor +E-help-wanted +A-rustbuild +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
But not everyone will want to run lldb, right? We only mention /usr/bin/python3 there, we don't actually run it unless lldb tests are run, which is pretty rare. This may still be an OK change, of course.
Sure - but in that case, we hardly need python at all, only for rustdoc tests, and it seems ok to use the system python.
I would actually support requiring Python 3 in any case.
let's please keep discussion about 2 vs 3 in and not relitigate it on each issue that mentions python.
claim
If I understand the issue here correctly, just moving the check from to the doesn't entirely remove the issue of needing the name defined on MacOS given the call to in To resolve this should the check in include a MacOS specific check for or an additional check for ?
The former - it should just use any time it needs python on MacOS, and remove the existing check for on that platform.
About to raise a PR, but is it even necessary to perform any check in if we are always forcing in Are there instances where won't be called before ? Also first time using , what would be the correct test to run here?
I don't think it's necessary to check in both places, no, you can return /usr/bin/python3 unconditionally in (). Whether you can remove the check in is a question for - I think probably yes, since you can still run the build without python, but it doesn't necessarily need to go in the same change switching to /bin/python3 consistently. Basically everything runs the check in , but I think it's only relevant when BOOTSTRAP_PYTHON is unset, so probably you'll need to make sure the check executes. If you want to check the version of python used works, you can run .

If we can rely on /usr/bin/python3 always existing on macOS there's no need to check for it, but I would expect that the code in isn't platform-specific and so should continue to look for python in a variety of ways (likely the same ways across all platforms). It looks like python is currently used for two separate things: lldb tests, and docck. The latter likely works with python 2 and python 3, or at least, so it's likely that we need to leave the discovery and configuration in place. Certainly on e.g. Windows /usr/bin/python3 is not expected to exist, I believe.