On 03/21/2015 12:56 PM, Aymeric Augustin wrote: > The lack of a fathomable way to get a functional logging config is a > huge pain point :-) > > In this case, I wish we improve Django’s logging tools rather than > document how to bypass them :-/
I agree. The current behavior is pretty bad in several ways, and we should fix it. I think the PR (with some modifications; I've commented on it) could be a stopgap improvement until that happens, though - it at least corrects some of the misinformation about `disable_existing_loggers` that our current docs contain. >> On 21 mars 2015, at 19:24, Tim Graham <timogra...@gmail.com >> <mailto:timogra...@gmail.com>> wrote: >> >> I think the lack of an obvious way to get a useful logging config for >> local development is a pain point we could address. >> >> Here's a patch from a contributor based on a blog post by Dan Poirier [1]: >> https://github.com/django/django/pull/4362 >> >> Do you think this is a good suggestion or do you have a different way >> of getting useful logging in development? >> >> I experimented a little with using an environment variable to modify >> parts of django.utils.log.DEFAULT_LOGGING to get a useful output if >> the env var is set to DEBUG, but it didn't seem so simple, besides a >> solution in django/utils/log.py like: >> >> if os.environ.get('DJANGO_CONSOLE_DEBUG'): >> DEFAULT_LOGGING = (default logging from pull request above) >> else: >> DEFAULT_LOGGING = (existing django.utils.log.DEFAULT_LOGGING) >> >> [1] >> http://www.caktusgroup.com/blog/2015/01/27/Django-Logging-Configuration-logging_config-default-settings-logger/ I think there are two mostly-separate questions being intertwined here. The first, more complex and more important question is: how do we fix Django's logging config process to be less broken, so that the best advice for getting it to do what you what isn't "disable Django's interference entirely and do it yourself."? I don't have a fully-packaged solution ready to propose here; someone will need to dig into it. Probably the biggest sticking point to get around will be backwards compatibility. I'm pretty sure that a good solution will include an optional way to prevent Django from ever installing its default logging config in the first place, since it seems there's no way to tell logging to "clear out everything and start fresh" once some configuration has been set. And I think it will also mean that we stop ever recommending the use of "disable_existing_loggers" (and probably even include a callout in our docs warning users against it). It seems that "disable_existing_loggers" is a bad feature with surprising behavior, and our current docs were written based on a misunderstanding of what it does. The second question is "how do I get useful logging for development?" I think that's actually a pretty easy question to answer, and the example config in the PR is basically correct (but currently located in the wrong section of the docs, IMO). We could easily make such a configuration the default behavior when `DEBUG` is on; I think that's worth exploring. Carl -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/550F7933.9070707%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
