-
Notifications
You must be signed in to change notification settings - Fork 25
remove logging.basicConfig() #18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alvinchow86 This logger will fail is logging hasn't been initialized previously, so it will work for you but not for someone who doesn't initialize the logger elsewhere.
After the creation of sift_logger, check if sift_logger has any handlers, and if not, run the logging.basicConfig command.
Should look like this
sift_logger = logging.getLogger('sift_client')
if not sift_logger.handlers:
logging.basicConfig()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I'll take a look. only thing is I'm running a Django app where I set a LOGGING dictionary in settings so I'm not explicitly calling logging.basicConfig/dictConfig/etc
|
@alvinchow86 Thanks for submitting this, before I can merge it we'd need to figure out how to maintain backwards compatibility. Did you have any suggestions on this? |
|
Huh, ran into this yesterday. We started using sift and were surprised to find that our logging configuration got messed up, just by importing a new library, without even calling anything in it. I mean, on one hand I understand the desire to make things "just work". But I'd definitely vote for removing it and calling it out as a breaking change. If sift does need to add logging handlers, I think it'd be better to do it the way Werkzeug does it (though it's worth noting that Werkzeug's a framework, not a library, so it's not surprising that it adds logging handlers). From https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/_internal.py#L75-L87 : def _log(type, message, *args, **kwargs):
"""Log into the internal werkzeug logger."""
global _logger
if _logger is None:
import logging
_logger = logging.getLogger('werkzeug')
# Only set up a default log handler if the
# end-user application didn't set anything up.
if not logging.root.handlers and _logger.level == logging.NOTSET:
_logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
_logger.addHandler(handler)
getattr(_logger, type)(message.rstrip(), *args, **kwargs)Then it's called like this: _log('info', ' * Restarting with reloader')Advantages:
(That |
|
How about ? It's a more focused approach and would not affect the global logging setup. |
|
We also installed |
|
@sww That's better, but I'd still argue installing handlers on import is unexpected behavior, especially for a library. Werkzeug's check for a root handler only works because it runs after client code has been initialized. |
|
Thanks, a better solution might be to just use |
|
@fredsadaghiani's fix was implemented in #31 |
|
Thank you! |
|
Great, thanks a bunch! |
|
Closing. See #31 instead. |
this library shouldn't be calling
logging.basicConfig(), since it's a global configuration and will muck with existing logging setups. I think this call is meant for the top-level application to control