Mitchell Hentges 14386d0c7e Bug 1717104: Activate virtualenv before running command r=perftest-reviewers,ahal,AlexandruIonescu ... All commands declaring a virtualenv will have them activated before the command executes. Removes all now-redundant manual activations of declared virtualenvs. Commands that don't declare a virtualenv will still implicitly be associated with the "common" virtualenv, but unlike explicit virtualenv declarations it'll have to be activated manually, just like it was before this patch. To smooth the migration with existing usages, virtualenv activation behaviour was changed slightly: if attempting to activate a new virtualenv, but the source venv is already command venv, then raise an exception. (In the future, we should improve testability of virtualenv scaffolding logic so that tests can be added for this sort of thing.) This did cause some issues with some tests, which will be solved more cleanly with bug 1724273. In the meantime, minimal modifications were made to failing tests to keep them green: * `test_command_line.py` was activating the `common` virtualenv so that it could install `mozproxy`, and use its CLI. Instead, I modified the test to use `mozproxy` using the "module" interface (`python -m mozproxy ...`). At that point, `MozbuildObject` was unnecessary and usages were replaced with simpler variants. * `test_vendor.py` needed its explicit `activate_virtualenv()` call patched out. It still needs to use a virtualenv's Python executable, but due to `sys.executable` now being kept up-to-date as of bug 1717051, it could be used directly. Differential Revision: https://phabricator.services.mozilla.com/D122892		2022-03-23 14:50:45 +00:00
..
index.rst	Bug 1717104: Activate virtualenv before running command r=perftest-reviewers,ahal,AlexandruIonescu	2022-03-23 14:50:45 +00:00