On May 28, 4:48 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > Following some discussion at the DjangoCon.eu sprints, here's what > we've got on the table regarding adding logging support to Django. > > The core of Vinay's work is essentially ready to go -- the logging > configuration code is an implementation of what has been accepted as a > PEP, so there's no reason for us to use anything else. > > As for landing this in trunk - the consensus is that this should be > done in two parts: > > The first commit will be the the actual core logging infrastructure - > the logging config parsing module, and the hooks to get a logging > configuration parsed and installed. > > The second commit will be the addition of actual logging. The > intention here is to be initially conservative; two immediate targets > would be to replace calls to mail_admins() with logging calls, and > replacing debug messages in management commands with their logging > equivalent.
Makes sense. > At this point, it largely becomes a political problem -- we don't want > Django's core to get bogged down in trivial logging calls, so we need > to develop our policy on when we add a logging statement to trunk, and > at what trace level, and so on. Of course, none of this prevents end > users from putting whatever logging they want into their own code. It > also doesn't prevent the core logging code and initial logging calls > being added to trunk; we can develop the logging policy over time once > the core is in place. > > On a technical level, the only issue that needs resolving is the issue > of how to trigger configuration of logging in the first place. The > current patch implements this using signals (a bootstrap plus pre/post > model load signals). The consensus at the sprints is that we should They're not of course signals in the dispatcher sense - just ordinary functions which get called back directly from the framework code. > take this opportunity to kill an old request -- 'startup' handling. > > Under this proposal, startup would look like this: > > * Once settings have been successfully imported, logging is > configured based on settings.LOGGING. This guarantees that logging > will always be configured, rather than relying on users successfully > invoking logging in their own settings file or similar. This will > essentially replace the BOOTSTRAP_CALLBACK in Vinay's current patch. > * We then look for a 'startup.py' in each app included in > INSTALLED_APPS, and import that module. This is the replacement for > (PRE|POST)_MODEL_CALLBACKS in Vinay's current patch Replacing the BOOTSTRAP_CALLBACK with auto-configuring logging via the LOGGING setting will of course work, but not be as flexible as things are at present. You won't be able to do anything else at that time - you just get logging configured for you, under the hood. Now that isn't a problem since the dictConfig API should handle all of the common and less-common scenarios, but if a user had a valid reason for doing logging configuration their own (different) way, or doing their own early-phase setup code, they'd be out of luck. > This provides a convenient entry point for configuration items such as > signals. The only runtime guarantee for startup.py is that the > > settings have been imported. This means that you should be able to > import models, register for signals, or anything else you may want to > do on startup. This implies that all the startup.py importing would be done in a separate loop after all the model loading is done - i.e. the equivalent of my POST_MODEL_CALLBACKS hook. If so, how could you hook into class_prepared, as per my example? Can you confirm that's the intention? Thanks for your feedback! Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
