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
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
Did you know that our version of requests was from 2015? Phwoar!
This bumps `jinja2`, `py`, `pyyaml`, `requests` and `urllib3`.
There's significant risk for regressions due to breaking changes,
though due to the dynamic nature of Python, they're tricky to track
down.
The potential breaking changes I'm expecting to potentially affect
us are:
* `requests@2.11.0`: No longer accepts non-strings as header values.
* `requests@2.16.0`: `requests.packages` namespace was removed due to
packages no longer being vendored. The namespace has been
incrementally restored over future releases, but it's unclear to
what degree.
* `requests@2.24.0`: Redirect resolution now only happens when
`allow_redirects` is `True`.
* `requests` version of `urllib3` was bumped from `1.13.1` to `1.26`,
unsure what repercussions that will have.
This also added dependencies to `flake8_requirements`. This is because
the vendored `importlib-metadata` update (and the new
`typing-extensions` dependency) is found by `pip`, but the
vendored `typing-extensions` is _not_ discovered (perhaps due to
details around "eggs" and the way we add vendored code to the sys.path).
So, `pip` tries to install it manually and fails when it finds no hash.
By re-compiling `flake8_requirements`, the necessary hashes are made
available.
Differential Revision: https://phabricator.services.mozilla.com/D108526
Did you know that our version of requests was from 2015? Phwoar!
This bumps `jinja2`, `py`, `pyyaml`, `requests` and `urllib3`.
There's significant risk for regressions due to breaking changes,
though due to the dynamic nature of Python, they're tricky to track
down.
The potential breaking changes I'm expecting to potentially affect
us are:
* `requests@2.11.0`: No longer accepts non-strings as header values.
* `requests@2.16.0`: `requests.packages` namespace was removed due to
packages no longer being vendored. The namespace has been
incrementally restored over future releases, but it's unclear to
what degree.
* `requests@2.24.0`: Redirect resolution now only happens when
`allow_redirects` is `True`.
* `requests` version of `urllib3` was bumped from `1.13.1` to `1.26`,
unsure what repercussions that will have.
This also added dependencies to `flake8_requirements`. This is because
the vendored `importlib-metadata` update (and the new
`typing-extensions` dependency) is found by `pip`, but the
vendored `typing-extensions` is _not_ discovered (perhaps due to
details around "eggs" and the way we add vendored code to the sys.path).
So, `pip` tries to install it manually and fails when it finds no hash.
By re-compiling `flake8_requirements`, the necessary hashes are made
available.
Differential Revision: https://phabricator.services.mozilla.com/D108526
Conflicting pylint requirements were causing the new pip dependency resolver
to report an error. This updates the dependencies for pylint (using the hashin package)
so that the conflict is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D106154
pylint_requirements.txt fail to install with the new pip resolver due
to a conflict between astroid and lazy-object-proxy.
Rather than bumping those packages and handling the potential fallout,
the package-upgrade has been deferred and we will use the legacy
resolver in the interrim.
Differential Revision: https://phabricator.services.mozilla.com/D99940
pylint_requirements.txt fail to install with the new pip resolver due
to a conflict between astroid and lazy-object-proxy.
Rather than bumping those packages and handling the potential fallout,
the package-upgrade has been deferred and we will use the legacy
resolver in the interrim.
Differential Revision: https://phabricator.services.mozilla.com/D99940
Before, on Windows, this resulted in installing the package in the parent environment (not the `virtualenv`). We fix this by passing down the `virtualenv_manager` so linters can install packages they need using that object's helper methods.
Differential Revision: https://phabricator.services.mozilla.com/D95738
The logic the `black` and `flake8` linters were using to find the location of the appropriate binaries for linting was wrong in certain cases given how `mach lint` uses subprocesses to batch work. Instead, we allow the option to override the old janky behavior with a known-good path.
Differential Revision: https://phabricator.services.mozilla.com/D95396
