forked from mirrors/gecko-dev
8d217e06a3
I'm guessing that the reason we haven't been building the Mach virtualenv in CI so far is because: * The default location in `~/.mozbuild` may not be cleared between jobs * There's a performance cost to `pip install`-ing packages, especially if they're not needed * In the past, it was tricky to have some jobs use a Mach virtualenv and others not. This led to weird workarounds where a virtualenv would be created, populated, then masqueraded as the "system Python" so that Mach would be able to run with access to its dependencies without needing to "create a Mach virtualenv". This patch addresses the first point about the Mach virtualenv location: In CI, if `WORKSPACE` is set, the Mach venv will be created in `$WORKSPACE/mach_virtualenv`. The other two points are solved by explicit configuration using the `MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE` environment variable. Differential Revision: https://phabricator.services.mozilla.com/D140256 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| docs | ||
| gdbpp/gdbpp | ||
| l10n | ||
| lldbutils | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozperftest | ||
| mozrelease | ||
| mozterm | ||
| mozversioncontrol | ||
| mach_commands.py | ||
| moz.build | ||
| README | ||
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Vendored python modules (use third_party/python instead) * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025