Python 3.9 support

[ml-evs]

This PR can be used to track Python 3.9 compatibility.

https://docs.python.org/3.9/whatsnew/3.9.html

[codecov]

Codecov Report

Merging #558 (6512198) into master (bf1f280) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #558   +/-   ##
=======================================
  Coverage   92.20%   92.20%           
=======================================
  Files          61       61           
  Lines        3246     3246           
=======================================
  Hits         2993     2993           
  Misses        253      253           

Flag	Coverage Δ
project	92.20% <ø> (ø)
validator	65.89% <ø> (+0.77%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bf1f280...6512198. Read the comment docs.

[ml-evs]

I think the main problem here is going to be waiting for pre-built wheels for e.g. pymatgen. I guess we could consider disabling the adapter tests for 3.9 (as they install many extra deps), but I'll convert this to a draft for now.

[CasperWA]

I think the main problem here is going to be waiting for pre-built wheels for e.g. pymatgen. I guess we could consider disabling the adapter tests for 3.9 (as they install many extra deps), but I'll convert this to a draft for now.

I wouldn't disable tests.
However, your comment here touches on a basic issue of this repository and the optimade package: How many of the package's capabilities must be valid before we consider the package valid, e.g., if only some adapter-conversions do not work, do we still consider the package valid as a whole?
I guess this comes down to the use case for depending on the optimade package.

On another note, I personally don't mind implementing a test for the used Python interpreter version when importing specific parts of the package that are clearly independent, e.g., the adapters versus the server.

[ml-evs]

On another note, I personally don't mind implementing a test for the used Python interpreter version when importing specific parts of the package that are clearly independent, e.g., the adapters versus the server.

Think this would be the best option, but we would still need to handle how the deps get installed (which in practice means disabling the adapter tests for 3.9)

[ml-evs]

How many of the package's capabilities must be valid before we consider the package valid, e.g., if only some adapter-conversions do not work, do we still consider the package valid as a whole?
I guess this comes down to the use case for depending on the optimade package.

On another note, I personally don't mind implementing a test for the used Python interpreter version when importing specific parts of the package that are clearly independent, e.g., the adapters versus the server.

These problems have fixed themselves for now, as all of our dependencies now have wheels for 3.9.

I can't see anything subtle that we'd have to change in our code base based on a quick read of https://docs.python.org/3.9/whatsnew/3.9.html so this should be good to go. It's a shame dependabot can't do this for us!