Closed Bug 1737208 Opened 3 years ago Closed 3 years ago

Typo for ./mach bootstrap command fails to recover

Categories

(Firefox Build System :: Bootstrap Configuration, defect, P5)

defect

Tracking

(firefox96 fixed)

RESOLVED FIXED
Tracking Status
firefox96 --- fixed

People

(Reporter: arai, Unassigned)

References

Details

Steps to reproduce:

  1. run ./mach botstrap

Actual result:

We're assuming the 'botstrap' command is 'bootstrap' and we're executing it for you.

Note on Artifact Mode:

Artifact builds download prebuilt C++ components rather than building
them locally. Artifact builds are faster!

Artifact builds are recommended for people working on Firefox or
Firefox for Android frontends, or the GeckoView Java API. They are unsuitable
for those working on C++ code. For more information see:
https://firefox-source-docs.mozilla.org/contributing/build/artifact_builds.html.

Please choose the version of Firefox you want to build:
  1. Firefox for Desktop Artifact Mode [default]
  2. Firefox for Desktop
  3. GeckoView/Firefox for Android Artifact Mode
  4. GeckoView/Firefox for Android
  5. SpiderMonkey JavaScript engine
Your choice:2
You can only create a mach environment with the system Python. Re-run this `mach` command with the system Python.
Error running mach:

    ['botstrap']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file bootstrap| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

subprocess.CalledProcessError: Command '['/Users/arai/.mozbuild/_virtualenvs/mach/bin/python', '/Users/arai/projects/mozilla-unified/mach', 'create-mach-environment']' returned non-zero exit status 1.

  File "/Users/arai/projects/mozilla-unified/python/mozboot/mozboot/mach_commands.py", line 42, in bootstrap
    bootstrapper.bootstrap(command_context.settings)
  File "/Users/arai/projects/mozilla-unified/python/mozboot/mozboot/bootstrap.py", line 342, in bootstrap
    self.instance.ensure_mach_environment(checkout_root)
  File "/Users/arai/projects/mozilla-unified/python/mozboot/mozboot/base.py", line 337, in ensure_mach_environment
    subprocess.check_call(cmd, cwd=checkout_root)
  File "/usr/local/Cellar/python@3.9/3.9.7_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)

it looks like it's using python in venv if it the command doesn't exist and it fixes up the command,
but bootstrap expects system python.

There's special handling for some commands, including bootstrap

https://searchfox.org/mozilla-central/rev/2e3b0483e31abffe0b4374480a34c6d23f5186ea/mach#14-20

# Commands that are to be run with the system Python 3 instead of the
# virtualenv.
nativecmds="
    bootstrap
    create-mach-environment
    install-moz-phab
"

https://searchfox.org/mozilla-central/rev/2e3b0483e31abffe0b4374480a34c6d23f5186ea/mach#112-117

# Check whether we need to run with the native Python 3 interpreter.
case " $(echo $nativecmds) " in
    *\ $command\ *)
        run_py python3 "$@"
        ;;
esac

The possible options here would be:

  • Mark those commands not recoverable from typo
  • Add yet another special handling about system python inside python/mach/mach/dispatcher.py

Tooru, you're on fire reporting these onboarding bugs, thank you :)
Two things about this bug:

  1. Though valid, there's a simple workaround, so I won't be able to prioritize it here
  2. It will be solved when we always use the Mach virtualenv and no longer have the "system/virtualenv" split on developer machines.
Priority: -- → P5

This should be fixed on central, as:

  • We don't need to invoke bootstrap with the system python anymore, and
  • There's no longer python-executable-switching happening based on parsed-argument before a Python interpreter is started.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.