Mach can currently only run on Python version 3.8 or higher, so it
doesn't make sense to continue having dead code that provides support
for Python2.
Differential Revision: https://phabricator.services.mozilla.com/D209030
This issue was introduced when D194599 moved the 'suggest' command logic
earlier in the mach initialization, so there was not a try/catch wrapper
to handle the error nicely.
Differential Revision: https://phabricator.services.mozilla.com/D204100
Aliased commands have not loaded the virtualenv associated with a
command/subcommand since bug 1695312. It has been defaulting to the
`common` virtualenv, which worked most of the time since most commands
use `common` and it also contains a large share of our dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D192376
Aliased commands have not loaded the virtualenv associated with a
command/subcommand since bug 1695312. It has been defaulting to the
`common` virtualenv, which worked most of the time since most commands
use `common` and it also contains a large share of our dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D192376
Since it depends on the `command_handlers` from `Registrar` for the
`file` `sub_command` to determine the appropriate component, we need to
load all command modules so that we can file against any of them.
Differential Revision: https://phabricator.services.mozilla.com/D184853
This just forces other command modules to be loaded in addition to the
'base' command. We need this so that decorators needed by the 'base'
command that are in another command module are ran during initialization
(eg: `@SettingsProvider`).
I thought about centralizing the `@SettingsProvider` decorators into one
module and always loading it, but they can depend on the
'command_handlers' in `Registrar`, so the modules they're currently in
have to be loaded for them to execute, so there wasn't a way around
this.
Differential Revision: https://phabricator.services.mozilla.com/D184852
This is really just shuffling a bunch of things around. None of the
'load_*' member functions of the `Mach` class actually needed to be
member functions. They can all be static so that they can be used
anywhere. That combined with moving all the other 'mach_command' logic
to a different file, allows us to load the module for any command so
that we can successfully dispatch it.
Differential Revision: https://phabricator.services.mozilla.com/D184060
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
We've had this restriction for a while (with a note of it in the docs,
but the note in the docs can easily be overlooked, leading to confusing
errors). Erroring out right on Mach startup and providing instructions
for the workaround immediately should help users get around this issue
faster.
Differential Revision: https://phabricator.services.mozilla.com/D183209
This makes loading almost all commands faster, since only one module
file is loaded rather than all of them. There is one main exception,
dealing with 'help'. Running `./mach help` (or -h or --help) requires
the description text for every command, so every module file is still
loaded.
We could expand this improvement here to consolidate all commands and
their parameters in this `MACH_COMMANDS` dict, but the only two benefits
are improving help, and not having two places where the commands are
specified (their file, and this dict).
There's a lot of extra work needed to do that, especially for handling
sub commands, and it did not seem worth the cost for the benefit at this
time.
Depends on D180499
Differential Revision: https://phabricator.services.mozilla.com/D180500
This activated virtualenv for a command is managed
`CommandSiteManager` and it is passed down to where it was activated
before to prevent a second, redundant, activation.
Differential Revision: https://phabricator.services.mozilla.com/D180499
Also add the associated virtualenv names to each command that has one in
preparation for loading the virtualenvs earlier (next patch).
Differential Revision: https://phabricator.services.mozilla.com/D181032
This reverts bug 1801826 and instead prepends the msys2 path only for
the build, which is a bit more sensible.
This allows us to remove the existing warning from old_configure, since
that can't happen now.
Differential Revision: https://phabricator.services.mozilla.com/D163073
This reverts bug 1801826 and instead prepends the msys2 path only for
the build, which is a bit more sensible.
This allows us to remove the existing warning from old_configure, since
that can't happen now.
Differential Revision: https://phabricator.services.mozilla.com/D163073
This makes sure that we find the right tools in the right msys2
environment in case we get called from another msys2 env.
Differential Revision: https://phabricator.services.mozilla.com/D162753
Added `mach uniffi generate` which executes `uniffi-bindgen-gecko-js` to
generate UniFFI bindings. It's unfortunate that we need to check these
files in, but I couldn't figure out a way to auto-generate them as part
of the build process.
Adding `#include "nsIContent.h"` to dom/base/nsINodeList.h. I think
that should have been present before, but things built okay because of
the way things got combined in the uniffied .cpp files. Adding these new
webIDL files bumped `NodeListBinding.cpp` to a new uniffied .cpp file
which caused the build to fail.
Differential Revision: https://phabricator.services.mozilla.com/D144468
Added `mach uniffi generate` which executes `uniffi-bindgen-gecko-js` to
generate UniFFI bindings. It's unfortunate that we need to check these
files in, but I couldn't figure out a way to auto-generate them as part
of the build process.
Adding `#include "nsIContent.h"` to dom/base/nsINodeList.h. I think
that should have been present before, but things built okay because of
the way things got combined in the uniffied .cpp files. Adding these new
webIDL files bumped `NodeListBinding.cpp` to a new uniffied .cpp file
which caused the build to fail.
Differential Revision: https://phabricator.services.mozilla.com/D144468
