Hi All,
A little off topic, but here's what I do to generate "yellow" html
tracebacks in production behind the scenes:
from django.views import debug
html = debug.ExceptionReporter(request, is_email=False, *sys.exc_info()).
get_traceback_html()
Though, I do that within the got_request_exception
What about the yellow 500 error-page when in debug-mode? I'd like to have a
copy of the complete thing *somewhere* now that what's sent by email is
sanitized. Cloning a running system, turning DEBUG on and attempting to
trigger the same error isn't always easy. Is the 500-data loggable at all?
On
On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote:
> And it still seems to me that it's bad for Django's default config to
> set `level: ERROR` and `propagate: False` on the django.request and
> django.security loggers, as that prevents those logs from propagating to
> higher-level handlers someo
I played around with this a bit, and it seems that if you
`disable_existing_loggers` but mention a specific pre-existing logger in
your new config, that logger (and its children) are not disabled. So in
your example here, because you're including the 'django' logger in your
new config, it and its c
Hm, now I wonder if that blog post in my initial post is entirely correct.
This config seems to send all Django logging to stdout (regardless of the
value of disable_existing_loggers). The difference from the initially
proposed doc patch is that this config redefines the 'django' logger
instead
On Monday, March 23, 2015 at 9:45:12 PM UTC+1, Wim Feijen wrote:
>
> This may sound stupid, but I actually use Logbook for logging because I
> find it easy to use.
>
Why would this sound stupid? Logbook is a nice library and actually worth
thinking about if we start using dependencies in Django.
This may sound stupid, but I actually use Logbook for logging because I
find it easy to use.
On Monday, 23 March 2015 18:48:26 UTC+1, Tim Graham wrote:
>
> The alternative to a new setting would be to revert the "merging" behavior
> of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING en
This is what we're using to send to loggly. I'm not honestly 100% sure it
works as intended but it gets the job done. It would be great if we could
conditionally log to console when running in a local dev environment.
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'form
On 03/23/2015 12:18 PM, Carl Meyer wrote:
> On 03/23/2015 11:48 AM, Tim Graham wrote:
>> The alternative to a new setting would be to revert the "merging"
>> behavior of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING
>> entirely. This original design was proposed by Claude in
>> https://
On 03/23/2015 11:48 AM, Tim Graham wrote:
> The alternative to a new setting would be to revert the "merging"
> behavior of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING
> entirely. This original design was proposed by Claude in
> https://code.djangoproject.com/ticket/18993#comment:7, b
The alternative to a new setting would be to revert the "merging" behavior
of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING entirely. This
original design was proposed by Claude in
https://code.djangoproject.com/ticket/18993#comment:7, but now we realize
disable_existing_loggers=Tru
On 03/22/2015 08:23 PM, Carl Meyer wrote:
> 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
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 seve
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 :-/
--
Aymeric.
> On 21 mars 2015, at 19:24, Tim Graham wrote:
>
> I think the lack of an obvious way to
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
15 matches
Mail list logo
