ocrd_cli_wrap_processor: always do initLogging

[bertsky]

fixes #1223 and replaces #1295

[bertsky]

(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.

[kba]

(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.)

I am wondering how future-proof these mechanisms are. There have been different workarounds to prevent tensorflow and others from logging, like our tf_disable_interactive_logs and various copy-and-pasted stanzas like in eynollah:

os.environ["TF_CPP_MIN_LOG_LEVEL"] = "3"
stderr = sys.stderr
sys.stderr = open(os.devnull, "w")
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")
warnings.filterwarnings("ignore")

And apart from being really intrusive and inconsistent, they could break at any point.

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.

Module-level in ocrd.decorators.__init__.py makes sense and a cursory glance over how eynollah and ocrd_kraken are structured make it seem this would work. For ocrd_calamari, there is a top-level __init__.py which does from .recognize import CalamariRecognize, i.e. tensorflow is imported before ocrd.decorators but it is guarded by tf_disable_interactive_logs.

So, as much as I dislike module-level function calls in general, in the interest of fewer surprises in the future, I'm for putting initLogging in ocrd.decorators.__init__.

[bertsky]

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

[bertsky]

Note to self: we still need that as part of v3 / new-processor-api as well → either we merge this before #1240 or we cherry-pick.