Calling the PythonInterpreter constructor set up some Python objects via
Boost Python before Python was properly initialized. This caused a segfault
in _PyObject_GC_Malloc in Python. Not sure what finally triggered that
segfault. Different Boost version? Different Python version? Different
compiler? Bruce Lee beating up Chuck Norris? https://youtu.be/HFm2L03AetU

OpenMM 7.7 checks for realistic parametrisation, e.g. that an angle between
three particles is in range [0, pi]. In the unit tests we just set random
values for testing that were outside that range. This triggered an OpenMM
error. The test values have been adapted accordingly.

Support for DSSP 4.0 (https://github.com/PDB-REDO/dssp) has been
enabled in commit da57a1f6.
This worked if CLIBD_MON env var points to some CCP4 related
compound library. In the example of dssp shipped with Debian
bullseye, that's not the case. The observation there:
It works if applied on a PDB file downloaded from RCSB with all bells
and whistles but it doesn't work if only the fix from the above commit
is applied. As OpenStructure implements all functionality from DSSP
(secondary structure and solvent accessibility), the binding to an
external program has been deprecated. dssp.AssignDSSP still exists,
but mimics the old behaviour using OpenStructure internal implementations.

in newer matplotlib versions (>=3.5) this will fail and fall back
to base kwarg

blastall is legacy

Versions are updated to what the mighty Schwede lab uses in production

Compilation was broken for years when IMG has been disabled.
IMG is now always built.

Otherwise it will fail if you provide a non-absolute working directory

Can either be pushed to standalone internal file format
or serve as starting point for MMTF / binaryCIF implementation
in OST. The stored data is kind of similar...

same as commit 69f90c46

makes it easier to re-use elsewhere