* Dependency bumps + related minor code tweaks
Resolves#13411: Bump black from 23.3.0 to 23.7.0 in /requirements
Resolves#13410: Bump django-allow-cidr from 0.6.0 to 0.7.1 in /requirements
Resolves#13409: Bump ruff from 0.0.277 to 0.0.278 in /requirements
Resolves#13408: Bump lxml from 4.9.2 to 4.9.3 in /requirements
Resolves#13406: Bump basket-client from 1.0.0 to 1.1.0 in /requirements
Resolves#13405: Bump sentry-sdk from 1.27.1 to 1.28.1 in /requirements
Resolves#13403: Bump pipdeptree from 2.9.4 to 2.10.1 in /requirements
Resolves#13402: Bump boto3 from 1.28.1 to 1.28.3 in /requirements
Resolves#13401: Bump django-cors-headers from 4.1.0 to 4.2.0 in /requirements
Resolves#13400: Bump cryptography from 41.0.1 to 41.0.2 in /requirements
* Bump ruff
* Fixup lint exclusion. The in-file noqa didn't work, so dropping that and keeping the pyproject.toml ref
* Move Bedrock to pip-compile-multi for easier Python dependency management
This changeset adds tooling to ease dependency management and also rationalises
our requirements files.
Before, we were just using hashin to manually hash pinned deps straight into a requirements file
Now we're using pip-compile-multi, which sits on top of pip-tools to do this.
We now get:
* Simpler syntax for adding and pinning dependencies via *.in files
* Automatic hash generation when the *.txt requirements files are produced
The dependency compilation/update tooling runs in a Docker container, so will be compatible
with the deployed service's containers.
We're also rationalising the existing split of dependency files:
* base -> being retired and used as the basis for prod requirements
* migration -> being retired and the two deps still useful to us (for moz-l10n-lint)
added to dev deps
* dev -> now extends from the prod requirements. We're not too concerned about image
size for dev and test builds
* prod -> still exists, but includes the base deps
* docs -> still exists as a standalone file, but also follows the "*.in"-file pattern
* Regenerate dependency files using pip-compile-multi
Note that to avoid clashes, the following balances were made:
* Keep meinheld at the lower version used in prod.txt, not the dev.txt one -- for now at least
* Downgrade Markdown to 3.3 to avoid a clash over importlib-metadata version
* Remove importlib-metadata==4.10.1 altogether as a hard pin and let pip-compile-multi work out the best fit
* Update docs to reference pip-compile-multi, replacing now-redundant notes on hashin
* Update Dockerfile to copy over and use freshly recut dependency files
* Attempting to tune deps to allow local builds to work, not just Docker ones
* Update pip-compile-multi config to inject a custom header that explains how to rebuild reqs
* Update Bedrock to use Python 3.9
* Update base images
* Update CI
* Update dependencies to make install run -- this involved manually using hashin to upgrade two hashed deps (greenlet and meinheld) then re-running make compile-requirements to update the top-level hash in prod.txt. It's a bit of a chicken-and-egg situation when the deps are built/re-locked in a container but you can't build the container itself unless the deps are viable, but it worked
* Upgrade everett in order to remove configobj, which is redundant and causing local install issues on MacOS M1
* Drop backports.cached-property and typed-ast from dev reqs because we don't need them on 3.9
* Update docs with local-installation guidance for pyenv and pyenv-virtualenv
* Remove 'upgrade requirements' option
Given that the --upgrade flag is implicitly / by-default true with
pip-compile-multi anyway, plus the fact we're hard-pininng everything,
there's no point having an explicit 'upgrade' path - so let's remove it
* Docs tweak to suggest simpler virtualenv name
* Update help option in Makefile
* Pin version of pip in the compile-requirements script
When unpinned, the build suddenly broke, so we're keeping it under strict
limits for now
* Upgrade Django to 2.2.27
* Upgrade newrelic package to latest, incl py3.9 support
* Switch to Python 3.9 Debian bullseye image, from buster
* Rationalise dependency input files to remove over-pinned subdeps
When we moved from hand-managed requirements.txt files, we were taking on files
that had literally every dependency and thier sub-deps in them. We don't want
the input (*.in) files to reference those subdeps, so this changeset tries to
thin things out and remove them
Note that the diff shows this was successful - there are very few changes to
the dependencies being mentioned in the output *.txt files, and the ones that
are there are all deliberate changes (eg removing 'pbr')
* Drop unused tenacity dep, bump APScheduler and link to a Python 3.9-patched version of mdx-outline
* Add --require-hashes option to pip usage in Dockerfile
It's implicitly set because the reqs files feature --hash=XXX
but better to be explicit
* Drop what appear to be redundant top-level dev dependencies
regex, pep8 and wcwidth appear to be subdeps that don't need pinning.
The others appear to not be in used, based on a search of the codebase.
Tests till pass
* Thin out some unnecessary top-level deps in prod.in
- funcsigs - old backport, redundant
- lxml - over-pinned subdep of BeautifulSoup?
- typing_extensions - over-pinned subdep
- zipp - over-pinned subdep
* Cap pip version to 21 for pip-compile-multi for now
* Reinstate lxml as a first-class dep: BeautifulSoup needs it as a user-specified parser
* Fix typo in pip-compile-multi header
* Hard-pin latest working combo of pip + pip-tools in compile-requirements.sh
* Update docs explaining why we're using 3.9.10 locally
* 10575: Update black configs to stop it skipping migration files
This brings it into line with isort running on all things.
Note: removing the `migrations` dir from the exclusions will broaden the scope of other tools that pre-commit uses, but this makes sense as black and isort will be targetting these, so why not flake8 too?
* 10575: Apply updated Black config to Bedrock migrations
* 10575: Update git-blame history ignoring for previous commit
* Update requirements to avoid requests version clash
* 10570: Add isort to project
* 10570: Add isort config to project
* 10570: Add isort as a test run/CI step
* 10570: Add isort to pre-commit config
* 10570: Update isort config to allow tests/pages.py to be first-party, which is more appropriate
* 10570: Apply isort to entire codebase, using project config
* 10570: Explicitly include lib/ as a first-party import
This behaviour is already implicit in the current config, but making it explicit, partly to protect against a future change. Also makes it easier to grok what will happen to various bedrock-codebase imports
* 10570: Update isort config to stack Django imports above third-party ones
* 10570: [nit-fix] Update run-tests.sh to call isort with the same syntax pattern as we call black
Rob Hudson
Steve Jalim