When becker and I looked into logging for libraries, the conclusion was that libraries use a NullHandler() and rely on the application to configure the loggers so that log messages came from the app, not the library. Perhaps this will solve the issue you indicated where the calling func and module are wanted, but unavailable. I'm less certain about the calling function, even though that would be useful: https://stackoverflow.com/questions/2654113/how-to-get-the-callers-method-name-in-the-called-method
Essentially, the NullHandler() ensures that the logging function calls are recognized and complete, but nothing is logged out unless the application does some configuration.
This patch extracts your logging configuration as-is, with the idea that we can demonstrate your logging format conventions, eventually push those changes into the apps, and revert the library back to the NullHandler() --or not-- by changing this isolated function definition.
Extract logger config.
When becker and I looked into logging for libraries, the conclusion was that libraries use a NullHandler() and rely on the application to configure the loggers so that log messages came from the app, not the library. Perhaps this will solve the issue you indicated where the calling func and module are wanted, but unavailable. I'm less certain about the calling function, even though that would be useful: https://stackoverflow.com/questions/2654113/how-to-get-the-callers-method-name-in-the-called-method
Essentially, the NullHandler() ensures that the logging function calls are recognized and complete, but nothing is logged out unless the application does some configuration.
This patch extracts your logging configuration as-is, with the idea that we can demonstrate your logging format conventions, eventually push those changes into the apps, and revert the library back to the NullHandler() --or not-- by changing this isolated function definition.