getLogger Irritation with regular CLI about dinglehopper HOT 5 CLOSED

Yes, this errror message bothered me too, last time I used the non-OCR-D CLI. I'll look into it

from dinglehopper.

The Problem could be worked around if you use OCR-D's initLogging also within the context of the non-OCR-D-CLI, adding in cli.py something like this:

I'm open to reintroducing on-the-fly initLogging() and dropping the error messages, as they should really be debug messages, maybe discuss in OCR-D/core#621

which couples it rather strong not only to the OCR-D-Logging-Logic, but also to it's configuration.

But is that such a bad thing? Reusing the OCR-D logging framework gives configuration files and globally overrideable log levels. My point is that it would benefit all things OCR-D if we improved the versatility/usability of the logging framework.

from dinglehopper.

@kba Totally agree in the realms of OCR-D. But this time its all about dinglehopper's non-OCR-D-CLI.
To be honest, I wasn't even able to figure out where the log messages are going after all.

from dinglehopper.

We now just call ocrd_utils' initLogging() in both the non-OCR-D CLIs dinglehopper and dinglehopper-extract to get this resolved!

from dinglehopper.

To be honest, I wasn't even able to figure out where the log messages are going after all.

To stdout, it seems.

from dinglehopper.