I chose to do this at the level of the outer Python invocation because:
1. `python -m cProfile ...` handles writing the file and some other
details. It's possible to rebuild the functionality -- the tools
are there -- but the APIs are awkward.
2. this allows to profile `mach` internals, instead of just the
invoked command's implementation.
This uses the return code of the `get_command` subshell to transmit
the single bit of information "is the flag present".
The Python-level argument is required in order to have `--help` know
about the option and to avoid the `mach` shell script having to filter
arguments.
Differential Revision: https://phabricator.services.mozilla.com/D116151
It's not practically make a difference (the flags we end up setting it
to don't do anything when linking all the wasm files into one).
Differential Revision: https://phabricator.services.mozilla.com/D116437
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
This could be easily generalized to avoid the updating the virtualenv
more generally, but I think this functionality should be in the
`virtualenv_manager` -- something like `install_pip_binary(...)` -- so
I've just done the most impactful example here.
Differential Revision: https://phabricator.services.mozilla.com/D116148
Another step towards avoiding the need for classes in mach commands;
here we are removing constructors either by changing them into helpers
or by simple refactorings.
Differential Revision: https://phabricator.services.mozilla.com/D112434
Now, when running mach commands that invoke `pip`, it will no longer
inform the user that it needs an update.
We reach into `distutils` to determine the "site-packages" directory
pattern, then apply it to our virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D115940
At least in PyCharm, expanding a `VirtualenvManager` instance means
resolving all the properties and fields of the instance.
However, if that property is doing non-trivial work, the debugger
wouldn't run that subprocess while we're stopped at a breakpoint.
So, the instance would sit there with the "Collecting data..." text.
Differential Revision: https://phabricator.services.mozilla.com/D115935
This was necessary before because we first started the build by invoking
make with client.mk, which would then invoke configure. But that changed
in bug 1671424, and we now never need make before configure has run
(except in tests, for which we implement a fallback).
Differential Revision: https://phabricator.services.mozilla.com/D116064
Another step towards avoiding the need for classes in mach commands;
here we are removing constructors either by changing them into helpers
or by simple refactorings.
Differential Revision: https://phabricator.services.mozilla.com/D112434
A clobber must be able to run, even if `substs` (configure output)
is not available.
However, when this behaviour was implemented, it was set up to replace
all usages.
Since we're trying to make mach commands no longer objects, this
kind of overriding won't be possible in the future. Fortunately, it's
not needed: only `Clobberer` needs a fallible substs, the other
consumers don't!
Differential Revision: https://phabricator.services.mozilla.com/D116128
Back-to-back `./mach clobber gradle` invocations were failing
because `shutil.rmtree(..)` would complain that the target directory
didn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D116129
No longer includes `python` in the `./mach clobber` defaults since
python cache files should no longer be affecting `./mach artifact`.
Removes `third_party/python` purging from `./mach clobber python`
since we don't build native Python modules there.
Moves virtualenv-purging from `./mach clobber objdir` to
`./mach clobber python`.
Differential Revision: https://phabricator.services.mozilla.com/D115728
Accidentally missing a `return` in a code path could mean that
`handle_package(...)` would accidentally do an action _and_
raise the "Unknown action" error.
This change resolves that, and it simplifies the code a bit.
Differential Revision: https://phabricator.services.mozilla.com/D115923
`MACH_VIRTUALENV` was never used, and `MOZBUILD_VIRTUALENV` was never
set (the virtualenv was always activated during the build, rather
than before).
Differential Revision: https://phabricator.services.mozilla.com/D115921
This was originally set up so that tests wouldn't "create a new
`virtualenv` for no reason." However, virtual environments now will have
different packages installed, and therefore the separation is necessary.
So, for the virtual environment used for builds (regular or for tests):
* We want it to be able to reuse the build venv, if it already exists.
* We don't want to pollute a `pytest` virtualenv with build-specific
packages.
Differential Revision: https://phabricator.services.mozilla.com/D115641
We had split up `init` from `init_py3` because `mach` had
traditionally been invoked by either Python 2 or Python 3, and
the two couldn't share the same virtualenv.
Now that the same context isn't shared by both Python 2 and 3
3
(developers always use Python 3, and the remaining Python 2
usages are CI jobs that never reuse the objdir with Python 3),
We can centralize on a single default virtualenv.
I've called this "common" instead of "init" to clarify its
existing position as the virtualenv that's used by many different
commands. As we associate virtualenvs with requirement definitions,
it'll also make the file less confusing: it's a "common" requirement
definition as opposed to an "init" one.
Differential Revision: https://phabricator.services.mozilla.com/D115635
Now, when running mach commands that invoke `pip`, it will no longer
inform the user that it needs an update.
We reach into `distutils` to determine the "site-packages" directory
pattern, then apply it to our virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D115940
At least in PyCharm, expanding a `VirtualenvManager` instance means
resolving all the properties and fields of the instance.
However, if that property is doing non-trivial work, the debugger
wouldn't run that subprocess while we're stopped at a breakpoint.
So, the instance would sit there with the "Collecting data..." text.
Differential Revision: https://phabricator.services.mozilla.com/D115935
We were raising an exception as a result of a python error
which was masked by a catch statement that thought we didn't
know how to remove the file. But we did.
Fix the python error, and add an exception at the end of the
function to be raised and then caught when we really don't know
how to remove a file.
Differential Revision: https://phabricator.services.mozilla.com/D115936
As a step towards moving mach commands outside of classes, this converts all
properties into methods so that they can later become top-level helper functions.
Differential Revision: https://phabricator.services.mozilla.com/D112196
Instead of using the pushlog, grab the hg log using a revset to avoid
being confused by branches: we're looking for revisions that are
ancestors of the new revision but not of the previous tag, i.e.
"current % previous".
Differential Revision: https://phabricator.services.mozilla.com/D115624
Instead of using the pushlog, grab the hg log using a revset to avoid
being confused by branches: we're looking for revisions that are
ancestors of the new revision but not of the previous tag, i.e.
"current % previous".
Differential Revision: https://phabricator.services.mozilla.com/D115624
Copy / migrate strings from onboarding/defaultBrowserNotification. Add updated ltr/rtl images and show them for pin and pin+default. Dynamically adjust steps and record telemetry to identify what was shown. Handle button actions based on string ids. Alias upgradeDialog to aboutwelcome for now. Avoid oddness with scrollbars by hiding horizontal scroll.
Differential Revision: https://phabricator.services.mozilla.com/D115142
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Added two fields:
1. Collect if the current shell is opened via vscode.
2. Connect if it's a remote ssh connection n the current shell.
Differential Revision: https://phabricator.services.mozilla.com/D114323
A `.arcconfig` may exist in the `.git` directory. Within worktrees,
the `.git` folder isn't at `<topsrcdir>/.git`, so we have to resolve it.
Differential Revision: https://phabricator.services.mozilla.com/D113320
While here, remove the unused clippyProcess.config. And because we need
to manipulate `$PATH` before running `cargo`, use the same wrapping
function in `get_clippy_version`.
Differential Revision: https://phabricator.services.mozilla.com/D113902
