Bump black packages to fix build failure

[michaeloliverx]

See comment at #535 (comment)

mkdocs==1.3.0
twine==4.0.0
black==22.3.0

[florimondmanca]

Yup seems like we also need to upgrade mkdocs - encode/httpx#2147

+ mkdocs build
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.9.10/x64/bin/mkdocs", line 8, in <module>
    sys.exit(cli())
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/mkdocs/__main__.py", line 187, in build_command
    build.build(config.load_config(**kwargs), dirty=not clean)
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/mkdocs/config/base.py", line 216, in load_config
    from mkdocs.config.defaults import get_schema
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/mkdocs/config/defaults.py", line 1, in <module>
    from mkdocs.config import config_options
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/mkdocs/config/config_options.py", line 8, in <module>
    from mkdocs import utils, theme, plugins
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/mkdocs/theme.py", line 6, in <module>
    from mkdocs.utils import filters
  File "/opt/hostedtoolcache/Python/3.9.10/x64/lib/python3.9/site-packages/mkdocs/utils/filters.py", line 13, in <module>
    @jinja2.contextfilter
AttributeError: module 'jinja2' has no attribute 'contextfilter'

[michaeloliverx]

Bumped mkdocs to 1.3.0 but there are some conflicts now:

The conflict is caused by:
    mkdocs 1.3.0 depends on importlib-metadata>=4.3
    twine 3.8.0 depends on importlib-metadata>=3.6
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
    flake8 4.0.1 depends on importlib-metadata<4.3; python_version < "3.8"

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

Anybody know a solution?

[florimondmanca]

We could try to upgrade everything we have issues with until things settle down...

• Upgrading to twine==4.0.0 (latest)?
• flake8 is already latest

[florimondmanca]

For context there seems to have a wider context around this importlib-metadata thing with flake8. See eg: edgi-govdata-archiving/web-monitoring-diff#94 (comment)

We might have to pin some things down for <3.8 to fit with flake8's current pin, which doesn't seem to change soon.

P.S. : CI fails with twine==4.0.0 because it looks like it dropped support on 3.6. Ha!

[tomchristie]

There's non-conflicting installs with higher versions of Python here. I think it's only across the range of different versions we're running that there's no good set of pin-to-this-exact-package-regardless-of-the-python-version.

Probably a cheap fix here is to just completely unpin twine (Shouldn't really be any reason much it'll need to be pinned, unlike eg. black or flake8 where different versions can cause different CI results.) We may as we completely unpin wheel there too. Hopefully having the "packaging" section unpinned will be enough to resolve this particular deadlock?

[michaeloliverx]

Closing in favour of #535