1785742 - Error running ./mach npm

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Shane Hughes [:aminomancer]]

I'm currently trying to follow this guide to compile the source files for about:welcome. I'm on Windows 10 using MozillaBuild 4. When I run ./mach npm [command], it fails like this:

$ ./mach npm
npm WARN config global `--global`, `--local` are deprecated. Use `--location=global` instead.
Error running mach:

    ['npm']

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 npm| 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:

mozbuild.base.BuildEnvironmentNotFoundException: config.status not available. Run configure.

  File "C:\mozilla-source\mozilla-unified\tools\mach_commands.py", line 495, in npm
    firefox_bin = command_context.get_binary_path(validate_exists=False)
  File "c:\mozilla-source\mozilla-unified\python\mozbuild\mozbuild\base.py", line 552, in get_binary_path
    substs = self.substs
  File "c:\mozilla-source\mozilla-unified\python\mozbuild\mozbuild\base.py", line 396, in substs
    return self.config_environment.substs
  File "c:\mozilla-source\mozilla-unified\python\mozbuild\mozbuild\base.py", line 372, in config_environment
    raise BuildEnvironmentNotFoundException(

Sentry event ID: cef2c5b379334f759cd4b4395da42366
Sentry is attempting to send 0 pending error messages
Waiting up to 2 seconds
Press Ctrl-Break to quit

I ran into this problem earlier today while working with a clone of mozilla-central. npm commands were working fine in that repo a month or two ago, but maybe something about my environment changed. So, I tried a clean install of MozillaBuild (deleting ~/.mozbuild too) and a new clone of mozilla-unified this time. But the same exact thing happened.

I've had some minor issues with MozillaBuild in the past that (I think) were caused by issues with environment variables. And I'm not sure what else could be the culprit, since I reinstalled MozillaBuild and started a new clone. So I tried tinkering around with my PATH. I actually tried adding MozillaBuild's node/npm folder to it, but that didn't help.

Here's what my PATH evaluates to in MozillaBuild:

$ echo $PATH
/c/Windows/System32/OpenSSH/
/c/mozilla-build/bin
/c/mozilla-build/kdiff3
/c/mozilla-build/python3
/c/mozilla-build/python3/Scripts
/usr/local/bin
/usr/bin
/bin
/opt/bin
/c/Program Files (x86)/Razer Chroma SDK/bin
/c/Program Files/Razer Chroma SDK/bin
/c/Program Files/Python37/Scripts
/c/Program Files/Python37
/c/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.2/bin
/c/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v10.2/libnvvp
/c/Program Files (x86)/Razer/ChromaBroadcast/bin
/c/Program Files/Razer/ChromaBroadcast/bin
/c/program files (x86)/common files/intel/shared libraries/redist/intel64/compiler
/c/program files (x86)/common files/oracle/java/javapath
/c/windows/system32
/c/windows
/c/windows/system32/wbem
/c/windows/system32/windowspowershell/v1.0
/c/windows/system32/openssh
/c/program files/nvidia corporation/nvidia nvdlisr
/c/program files (x86)/highpoint technologies, inc/highpoint raid management/service
/c/Program Files/dotnet
/c/ProgramData/chocolatey/bin
/c/Program Files (x86)/Insta360Stitcher/tools/proStitcher
/c/Program Files/7-Zip
/c/Users/shmed/AppData/Local/Microsoft/WindowsApps
/c/tools/dart-sdk/bin
/c/Program Files/NVIDIA Corporation/Nsight Compute 2019.5.0
/c/Program Files/Common Files/Autodesk Shared
/c/Program Files (x86)/Autodesk/Backburner
/c/Users/shmed/AppData/Local/Programs/Microsoft VS Code/bin
/c/Users/shmed/AppData/Local/Programs/Microsoft VS Code
/c/Users/shmed/AppData/Local/GitHubDesktop/bin
/c/Program Files (x86)/ClockworkMod/Universal Adb Driver
/c/Users/shmed/Documents/Portable Software/platform-tools
/c/mingw/local64/bin-video
/c/mingw/local64/bin-audio
/c/mingw/local64/bin-global
/c/Users/shmed/AppData/Roaming/Pub/Cache/bin
/c/Program Files/Git/cmd
/c/Users/shmed/.mozbuild/node
/c/mozilla-build/python3/Scripts
/c/mozilla-build/python3
/c/WINDOWS/system32
/c/WINDOWS
/c/WINDOWS/System32/Wbem
/c/WINDOWS/System32/WindowsPowerShell/v1.0
/c/WINDOWS/System32/OpenSSH
/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common
/c/Program Files/Calibre2
/c/Users/shmed/.cargo/bin
/c/Users/shmed/AppData/Local/hyper/app-3.0.2/resources/bin
/c/Users/shmed/AppData/Roaming/nvm
/c/Program Files/nodejs
/c/Users/shmed/AppData/Roaming/Python/Python37/Scripts
/usr/bin/site_perl
/usr/bin/vendor_perl
/usr/bin/core_perl

So, I decided to try following the instructions I linked above, but replacing ./mach npm with ~/.mozbuild/node/npm instead. And this seems to work. The install worked but the run bundle step failed when I tried it on my original mozilla-central clone, telling me that caniuse-lite is outdated. But when I try it on my new mozilla-unified clone, it all works without a hitch and I'm able to compile the source files.

But yeah, I'm hoping to be able to use ./mach npm and have it find the right executables. Or maybe it is finding the right executables but something else is going wrong. If mach is not doing anything special to use its own node/npm version, and it's just parsing the path, then shouldn't the path above lead it to /c/Users/shmed/.mozbuild/node? So idk why I'm getting different results running ./mach npm than I get from running ~/.mozbuild/node/npm. Unless the order is backwards and I'm just misunderstanding how it works.

Anyway, this sounds a lot like bug 1716257. I thought it might be the same bug, but that one has apparently been fixed a year ago.

Comment 1

[Shane Hughes [:aminomancer]]

Maybe has something to do with bug 1762571! I hadn't tried ./mach npm since before that landed so maybe that's it.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

But yeah, I'm hoping to be able to use ./mach npm and have it find the right executables. Or maybe it is finding the right executables but something else is going wrong. If mach is not doing anything special to use its own node/npm version, and it's just parsing the path, then shouldn't the path above lead it to /c/Users/shmed/.mozbuild/node?

Agreed, that's what I'd expect too.

If things we're working until a few months ago, I'd suspect the Node 14 upgrade too.

Does ./mach bootstrap help?

Do you have a config.status in either the top-level of your build tree or an objdir?

Comment 3

[Shane Hughes [:aminomancer]]

Attachment: config.status

(In reply to Dan Mosedale (:dmosedale, :dmose) from comment #2)

Does ./mach bootstrap help?

Hey, thanks. I tried bootstrap after I first encountered the problem since it helped with issues I had in the past, but in this case it didn't. Nor with vcs-setup or doctor.

Do you have a config.status in either the top-level of your build tree or an objdir?

Yeah, in the objdir. I'll attach it.

Comment 4

[Alex Hochheiden [:ahochheiden] (needinfo? me)]

Sorry for the delay.

:aminomancer my best guess is that you have a MOZCONFIG environment variable set to point to one that you forgot about.

In the config.status you linked it shows: mozconfig = 'C:\\Users\\shmed\\.mozconfigs\\artifact' (which doesn't look like the default).

Check your environment variables, delete MOZCONFIG it if it's there, restart your shell, clobber, then see if this still occurs.

Comment 5

[Shane Hughes [:aminomancer]]

(In reply to Alex Hochheiden [:ahochheiden] from comment #4)

Sorry for the delay.

:aminomancer my best guess is that you have a MOZCONFIG environment variable set to point to one that you forgot about.

In the config.status you linked it shows: mozconfig = 'C:\\Users\\shmed\\.mozconfigs\\artifact' (which doesn't look like the default).

Check your environment variables, delete MOZCONFIG it if it's there, restart your shell, clobber, then see if this still occurs.

Thanks for the suggestions Alex. I'm actually using mozconfigwrapper. The mozconfig files have the usual autoclobber option, and the artifact file is the same as the default file mach bootstrap builds if you choose artifact mode. The non-artifact file has an additional non-default option, but I haven't used that mozconfig in about a month.

# mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/artifact
mk_add_options AUTOCLOBBER=1
ac_add_options --enable-artifact-builds

# mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/artifact
mk_add_options AUTOCLOBBER=1
ac_add_options --with-ccache=sccache

Anyway, the problem spontaneously resolved yesterday and I was able to return to using ./mach npm. I wish I knew when and how it happened so I could offer more info. I must have clobbered like 50 times so idk what it could realistically be. Does the .mozbuild/srcdirs/mozilla-unified/_virtualenvs/ folder rebuild itself on every clobber?

Comment 6

[Alex Hochheiden [:ahochheiden] (needinfo? me)]

That's where the mach virtualenv lives, so running any ./mach command will create that virtualenv if it doesn't already exist, but ./mach clobber will never 'clobber' the mach virtualenv inside .mozbuild, only the virtualenvs inside the objdir. Did you delete that one yourself manually?

Comment 7

[Shane Hughes [:aminomancer]]

(In reply to Alex Hochheiden [:ahochheiden] from comment #6)

That's where the mach virtualenv lives, so running any ./mach command will create that virtualenv if it doesn't already exist, but ./mach clobber will never 'clobber' the mach virtualenvinside.mozbuild, only the virtualenvs inside theobjdir`. Did you delete that one yourself manually?

Exactly, but I actually deleted it after the problem disappeared. I'm not sure if it's related but this morning I was getting an error on every mach command that some file in there was missing. So I just deleted the mach folder in there and ran the mach command again, it created and populated a new folder, and mach commands started working again.

So I thought that might be connected. But again, the virtualenv issue didn't emerge until today, and the ./mach npm issue resolved yesterday. I was using ./mach npm without any problems yesterday and then today I ran into this new issue, but was able to fix it really quickly by just deleting that folder.

Comment 8

[Alex Hochheiden [:ahochheiden] (needinfo? me)]

That's odd, I've never seen an issue with the mach virtualenv. Do you happen to still have the error message available to share?

Comment 9

[Shane Hughes [:aminomancer]]

(In reply to Alex Hochheiden [:ahochheiden] from comment #8)

That's odd, I've never seen an issue with the mach virtualenv. Do you happen to still have the error message available to share?

Unfortunately not, unless they automatically get dumped somewhere? Yeah, it is the first time I have seen anything like it. I figured something must have been hanging the last time I quit the shell

Comment 10

[Alex Hochheiden [:ahochheiden] (needinfo? me)]

Oh well, if you encounter it again don't hesitate to share.

I'll close this bug out since there's nothing actionable at the moment.