Enforce Jinja2 3.x

[CasperWA]

As seen in this workflow Jinja2 v3.x is uninstalled and Jinja2 v2.x is installed instead when installing the client requirements.

This results in an ImportError from markupsafe (see this issue).
There are two solutions to this issue:

1. Pin markupsafe
2. Enforce Jinja2 3.x

I prefer the second option as we're already using Jinja2 v3.x in the CI through requirements.txt, but allowing Jinja2 v2.x in setup.py. However, it may be that some of the client dependencies do not allow this. Then we'd need to go for the first option above I suppose. But would need to keep an eye out for when the dependency then updates to use Jinja2 v3.x and remove the markupsafe pin.

[ml-evs]

Our use of jinja is so superficial (no loops, only one conditional) that I wouldn't be against dropping the dep and just writing a static HTML file ourselves when the server starts. Only issue would be how careful we need to be with input sanitation, but we can use pydantic for that anyway.

[CasperWA]

Fair enough. I think there's an issue then with the client dependencies, which may not have solved this problem - but that's essentially out of our control, I suppose.

[ml-evs]

Just revisiting this, isn't the whole problem that AiiDA is pinned to jinja2<=2 , which is why we had to allow it too? The tests only fail after the aiida install step

[ml-evs]

You can see us having the exact same discussion less than a year ago, hah #838

[CasperWA]

Just revisiting this, isn't the whole problem that AiiDA is pinned to jinja2<=2 , which is why we had to allow it too? The tests only fail after the aiida install step

Yeah. Can we try to maybe install jinja2>=3 after installing AiiDA to see if it works?

[ml-evs]

So looks like this also affects mkdocs, as shown in https://github.com/Materials-Consortia/optimade-python-tools/runs/5360468940?check_suite_focus=true

[ml-evs]

Ugh, my bad, I didn't remove the old pinned version from the setup.py.

[CasperWA]

Ugh, my bad, I didn't remove the old pinned version from the setup.py.

Right! Well spotted.

Create a new PR that references and closes #1079 and then we can close #1086 if the CD succeeds afterwards.