Convert mozprocess references in tools/lint to use subprocess instead: with this change, subprocess is used consistently throughout tools/lint. mozprocess is poorly maintained and can be easily replaced with modern subprocess.
Differential Revision: https://phabricator.services.mozilla.com/D190696
Because we use an older version of Python than the one generally used on
the host system, this implied enforcing a few package requirements.
Differential Revision: https://phabricator.services.mozilla.com/D180057
Please see comments in bug report for more details. I'm unfamiliar with this part of the codebase / typed_ast, so hopefully somebody with more experience can take a look at this.
Differential Revision: https://phabricator.services.mozilla.com/D172611
This is enabling the PLE and PLC rules across a much larger swatch of the code
base. The PLR and PLW are additionally enabled at the warning level (introduces
~2500 new warnings).
To avoid extraneous changes in people's patches, rules at the warning level are
excluded from --fix.
Differential Revision: https://phabricator.services.mozilla.com/D172358
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
This is enabling the PLE and PLC rules across a much larger swatch of the code
base. The PLR and PLW are additionally enabled at the warning level (introduces
~2500 new warnings).
To avoid extraneous changes in people's patches, rules at the warning level are
excluded from --fix.
Differential Revision: https://phabricator.services.mozilla.com/D172358
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
Moves the lint and setup functions to more generic versions that accept "locale"
and "repo" as arguments. Functions with the original names call these with the
module globals.
This will allow for the l10n linter configuration in comm-central to have just
lint and setup functions that pass appropriate values rather than duplicating
most of the code in this file. See bug 1799496.
Differential Revision: https://phabricator.services.mozilla.com/D164922
This makes it possible to use the resolve all configs option and set up
different first party modules for different directories.
The downside is that configuration options (e.g. profile = black) have to
be repeated in every .isort.cfg file, because isort never merges configuration
files.
Differential Revision: https://phabricator.services.mozilla.com/D163567
In addition to showing the `pip check` failure, also show:
* The `pip install --requirements ...` output
* The output of `pip list -v`
* The path to the `requirements.txt` file and the affected site.
To get sufficient detail of `pip install --requirements` to display
if the subsequent `pip check` call failed, I had to remove the
`--quiet` parameter. It was replicated by hiding _all_ output
if `quiet=True` and `pip install` succeeds - this is different to
the previous behaviour, where warnings would still poke through,
even if `quiet=True` and the install succeeded.
This was the only way to make it work such that all output would
be available without having to run `pip install` twice (which would
likely get different output the second time). Besides, there weren't
many warnings triggering this edge case, so the change in behaviour is
probably acceptable.
Additionally, in both places doing `pip check`
(post-install-requirements and when doing system-package compatibility
checking), move the `pip check` output to happen last, so that users
don't need to scroll to the top of the `pip list` wall of text to find
the reason for their command failure.
Differential Revision: https://phabricator.services.mozilla.com/D137206
Black and PyLint linters fail to install with Python 3.10 because of typed-ast.
typed-ast 1.4.3 added support for Python 3.10.
Differential Revision: https://phabricator.services.mozilla.com/D135538
Build and run the Mach virtualenv from a `state_dir` that is
"specific-to-topsrcdir".
As part of this, move `get_state_dir()` to `mach` so that it's usable
before `sys.path` entries are fully set up.
Differential Revision: https://phabricator.services.mozilla.com/D130383
This makes sure colorama stays in pylint_requirements.txt next
time someone regenerates it on a non-Windows machine. Since
colorama is only required by pylint on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D128426
