1717630 - create-mach-environment fails with Exception: Unknown action: comm.pth

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[:Gijs (he/him)]

Running ./mach bootstrap after clobbering produces this error from mach create-mach-environment

created virtual environment CPython3.9.1.final.0-64 in 384ms
  creator CPython3Posix(dest=$HOME/.mozbuild/_virtualenvs/mach, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=$HOME/Library/Application Support/virtualenv)
    added seed packages: pip==20.3.1, setuptools==51.0.0, wheel==0.36.1
  activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
Traceback (most recent call last):
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 755, in <module>
    manager.populate()
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 407, in populate
    handle_package(current_action, current_package)
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 343, in handle_package
    submanager.populate()
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 407, in populate
    handle_package(current_action, current_package)
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 358, in handle_package
    handle_package(*package.split(":", maxsplit=1))
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 343, in handle_package
    submanager.populate()
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 407, in populate
    handle_package(current_action, current_package)
  File "$SRCDIR/python/mozbuild/mozbuild/virtualenv.py", line 367, in handle_package
    raise Exception("Unknown action: %s" % action)
Exception: Unknown action: comm.pth
Error running mach:
​
    ['create-mach-environment']

Comment 1

[:Gijs (he/him)]

After running mach create-mach-environment separately and then mach bootstrap, both now appear to work... 🤷‍♂️

Comment 2

[Mitchell Hentges [:mhentges] 🦀]

Did you have a local thunderbird checkout at $srcdir/comm?
Did you pull it after the original ./mach bootstrap failure?

I'm guessing that it was out-of-date, and now it's synchronized again.

Comment 3

[:Gijs (he/him)]

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #2)

Did you have a local thunderbird checkout at $srcdir/comm?

It's a symlink, but yes.

Did you pull it after the original ./mach bootstrap failure?

No. I checked, and the tree in there is from August last year, and still doesn't appear to have newer commits in the repo.

I'm guessing that it was out-of-date, and now it's synchronized again.

Hm, how does this symlink interfere with things?

Comment 4

[Mitchell Hentges [:mhentges] 🦀]

Hm, how does this symlink interfere with things?

The virtualenv-setup logic is being modified and simplified to enable requiring packages from PyPI.
The comm repo needs to be adjusted accordingly to keep it up-to-date.

I don't really like the interaction point between Thunderbird and Firefox for the virtualenv, but it's the current state, for better or for worse.

No. I checked, and the tree in there is from August last year, and still doesn't appear to have newer commits in the repo.

Hmm, I wouldn't doubt that the existing virtualenv code doesn't properly manage failures when it's halfway through building the virtualenv - I wonder if simply running ./mach create-mach-environment the second time is what "fixed" it (or, at least, it didn't raise an exception the second time).

Comment 5

[Mitchell Hentges [:mhentges] 🦀]

Hmm, I wouldn't doubt that the existing virtualenv code doesn't properly manage failures when it's halfway through building the virtualenv - I wonder if simply running ./mach create-mach-environment the second time is what "fixed" it (or, at least, it didn't raise an exception the second time).

Hah! Just saw you create this bug.
Try:

1. Update your thunderbird checkout, or remove the symlink
2. ./mach create-mach-environment -f

I'll continue doing some digging to improve virtualenv resilience to construction failures :)

Comment 6

[:Gijs (he/him)]

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #5)

Hmm, I wouldn't doubt that the existing virtualenv code doesn't properly manage failures when it's halfway through building the virtualenv - I wonder if simply running ./mach create-mach-environment the second time is what "fixed" it (or, at least, it didn't raise an exception the second time).

Hah! Just saw you create this bug.
Try:

1. Update your thunderbird checkout, or remove the symlink
2. ./mach create-mach-environment -f

This did not help, the same failure occurs with ./mach build. I also tried ./mach clobber prior to ./mach create-mach-environment -f, which made no difference.

Comment 7

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #6)

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #5)

Hmm, I wouldn't doubt that the existing virtualenv code doesn't properly manage failures when it's halfway through building the virtualenv - I wonder if simply running ./mach create-mach-environment the second time is what "fixed" it (or, at least, it didn't raise an exception the second time).

Hah! Just saw you create this bug.
Try:

1. Update your thunderbird checkout, or remove the symlink
2. ./mach create-mach-environment -f

This did not help, the same failure occurs with ./mach build. I also tried ./mach clobber prior to ./mach create-mach-environment -f, which made no difference.

To be clear, I first tried updating the checkout and then running ./mach create-mach-environment -f (didn't work), then removing the symlink and re-running (didn't work), then clobbering and re-running. I just manually moved the $HOME/.mozbuild/_virtualenvs/mach dir out of the way and re-ran the whole sha-boodle, and I'm still not able to run ./mach build - the failure in bug 1717635 persists.

Comment 8

[:Gijs (he/him)]

Hm, finally, removing rm -rf $OBJDIR/_virtualenvs/ worked.

Comment 9

[Mitchell Hentges [:mhentges] 🦀]

Hm, finally, removing rm -rf $OBJDIR/_virtualenvs/ worked.

👍 Nice, right, more than just the top-level mach virtualenv were affected I see.
I've reported a bug over here to handle the issue where broken venvs were assumed stable.

---

I'm closing this bug since the top-level issue was an out-of-date thunderbird checkout.