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.

If fault_tolerant is enabled, it might happily read a cif file as PDB file.
As a consequence, there are no residues in the returned entity.

QT5 may cause hard to interpret import errors on older Linux kernels:
https://bbs.archlinux.org/viewtopic.php?id=232682

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