Bug 1713857: Don't set PYTHONEXECUTABLE environment variable r=glandium

After some testing in `try` and locally, the manual
`PYTHONEXECUTABLE` definitions shouldn't be needed
anymore.

There's been some work on Brew's
Python to improve its `sitecustomize` behaviour.
The most likely improvement is:
https://github.com/Homebrew/homebrew-core/pull/65297

However, I'm not fully confident in this change.
If it fails, it's more likely to affect developers
than CI. I think it's worth attempting a landing,
because if the variable is indeed obsolete, then
deleting it will avoid some spicy "action-at-a-
distance" behaviour.

Differential Revision: https://phabricator.services.mozilla.com/D117452
This commit is contained in:
Mitchell Hentges
2021-06-17 13:28:29 +00:00
parent b4eabfc057
commit 1a8c70c702
3 changed files with 4 additions and 34 deletions

View File

@@ -350,10 +350,6 @@ def virtualenv_python3(env_python, build_env, mozconfig, help):
log.info("Re-executing in the virtualenv")
if env_python:
del os.environ["PYTHON3"]
# Homebrew on macOS will change Python's sys.executable to a custom
# value which messes with mach's virtualenv handling code. Override
# Homebrew's changes with the correct sys.executable value.
os.environ["PYTHONEXECUTABLE"] = python
# Another quirk on macOS, with the system python, the virtualenv is
# not fully operational (missing entries in sys.path) if
# __PYVENV_LAUNCHER__ is set.
@@ -366,11 +362,6 @@ def virtualenv_python3(env_python, build_env, mozconfig, help):
if not distutils.sysconfig.get_python_lib():
die("Could not determine python site packages directory")
# We may have set PYTHONEXECUTABLE above, and that affects python
# subprocesses we may invoke as part of configure (e.g. hg), so
# unset it.
os.environ.pop("PYTHONEXECUTABLE", None)
str_version = ".".join(str(v) for v in version)
return namespace(

View File

@@ -13,11 +13,7 @@ from multiprocessing import cpu_count
import six
from concurrent.futures import (
ThreadPoolExecutor,
as_completed,
thread,
)
from concurrent.futures import ThreadPoolExecutor, as_completed, thread
import mozinfo
from mozfile import which
@@ -26,11 +22,7 @@ from manifestparser import filters as mpf
from mozbuild.base import MachCommandBase
from mach.decorators import (
CommandArgument,
CommandProvider,
Command,
)
from mach.decorators import CommandArgument, CommandProvider, Command
from mach.util import UserError
here = os.path.abspath(os.path.dirname(__file__))
@@ -74,9 +66,7 @@ class MachCommands(MachCommandBase):
self.log_manager.terminal_handler.setLevel(logging.CRITICAL)
# Note: subprocess requires native strings in os.environ on Windows.
append_env = {
"PYTHONDONTWRITEBYTECODE": str("1"),
}
append_env = {"PYTHONDONTWRITEBYTECODE": str("1")}
if requirements and no_virtualenv:
raise UserError("Cannot pass both --requirements and --no-virtualenv.")
@@ -249,8 +239,7 @@ class MachCommands(MachCommandBase):
and test["requirements"] not in installed_requirements
):
self.virtualenv_manager.install_pip_requirements(
test["requirements"],
quiet=True,
test["requirements"], quiet=True
)
installed_requirements.add(test["requirements"])
@@ -351,14 +340,6 @@ class MachCommands(MachCommandBase):
else:
env["PYTHONDONTWRITEBYTECODE"] = "1"
# Homebrew on OS X will change Python's sys.executable to a custom value
# which messes with mach's virtualenv handling code. Override Homebrew's
# changes with the correct sys.executable value.
if six.PY2:
env[b"PYTHONEXECUTABLE"] = python.encode("utf-8")
else:
env["PYTHONEXECUTABLE"] = python
proc = ProcessHandler(
cmd, env=env, processOutputLine=_line_handler, storeOutput=False
)

View File

@@ -223,8 +223,6 @@ class VirtualenvManager(VirtualenvHelper):
def _log_process_output(self, *args, **kwargs):
env = kwargs.pop("env", None) or os.environ.copy()
# PYTHONEXECUTABLE can mess up the creation of virtualenvs when set.
env.pop("PYTHONEXECUTABLE", None)
kwargs["env"] = ensure_subprocess_env(env)
if hasattr(self.log_handle, "fileno"):