1727819 - Guard against risky virtualenv=>virtualenv activations

Status: RESOLVED FIXED

(Firefox Build System :: Mach Core, task)

Description

[Mitchell Hentges [:mhentges] 🦀]

As we're going to have per-command virtualenvs, and we can't guarantee compatibility between commands, we're going to have to remove mach_context.commands.dispatch(...) support.

Comment 1

[Mitchell Hentges [:mhentges] 🦀]

Hmm, there's a lot of cases where we're taking advantage of running subsequent commands in the same process by passing pre-parsed values directly into the called command with **kwargs.
There's cases like ./mach try that dynamically calls ./mach try again/fuzzy/auto/etc [*args], or ./mach hazards compile that ferries arguments to ./mach build.

We have couple options of solving this:

• Add infrastructure to pass along "pre-parsed" arguments to subprocesses (assuming that the parsed variants can all be serialized).
• Add infrastructure to convert parsed arguments back into --command --line --flags.
• Or, the easiest solution: continue to allow .dispatch() to exist, but validate that the virtualenv_name isn't changing between the calling and callee commands.

Comment 2

[Mitchell Hentges [:mhentges] 🦀]

Even better, tweaked this a little further to a better abstraction level: forget dispatching, just guard against activating a command virtualenv from another command virtualenv.

Comment 3

[Mitchell Hentges [:mhentges] 🦀]

Attachment: Bug 1727819: Remove redundant virtualenv activation for docs

Sphinx already runs within the ./mach doc command, which has the
docs virtualenv activated. Activating another virtualenv within a
Sphinx python file is redundant.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/85c1380a7969
Remove redundant virtualenv activation for docs r=ahal

Comment 5

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/85c1380a7969

Comment 6

[Mitchell Hentges [:mhentges] 🦀]

Attachment: Bug 1727819: Guard against command site -> another site activations

The Mach site is asserted to be compatible with all command sites, but
command sites are deliberately //not// asserted to be compatible with
each other - they're //supposed// to have the flexibility of being
able to be incompatible.

Accordingly, let's fail loudly if code tries to activate from one
command site to another.

This required updating the mozproxy tests, who would deliberately
activate the common site so they could call a mozproxy entry point
script. These tests were fixed by instead invoking mozproxy as a
module (-m) of the current python-test site.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/349b88dc2b26
Guard against command site -> another site activations r=ahal

Comment 8

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/349b88dc2b26