(Of course, as already commented in #1223, it may still be necessary to be careful with imports on the side of the processor implementations. For example, moving import tensorflow to setup.)

Alternatively, we could still do initLogging on the module level, though not in ocrd_utils.logging but rather ocrd.decorators, which arguably will only be imported by applications that do need log handlers.

There have been different workarounds to prevent tensorflow and others from logging, like our tf_disable_interactive_logs

right, but that just covers the rogue print and write statements scattered across Keras and TF (so interactive_logs is actually a misnomer within Keras itself)

and various copy-and-pasted stanzas like in eynollah:

os.environ["TF_CPP_MIN_LOG_LEVEL"] = "3"

That should not be necessary if we run our initLogging before TF can do theirs, since we already set the level for tensorflow to error (i.e. 3).

stderr = sys.stderr
sys.stderr = open(os.devnull, "w")

wow, that's rather extreme, it speaks to the frustration that we had with correct logging setup in the Python ecosystem

import tensorflow as tf
from tensorflow.python.keras import backend as K
from tensorflow.keras.models import load_model
sys.stderr = stderr
tf.get_logger().setLevel("ERROR")

should also not be necessary anymore

warnings.filterwarnings("ignore")

That's something we could indeed add into ocrd_cli_wrap_processor in the non-processing contexts