Hi all, 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. 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 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 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. There won't be a project-level startup file. We've been trying to discourage the use of projects for a long time, and almost everything that needs to be considered as "project level" can be implemented by using a "project app" -- either adding a 'project.core' app to the mix, or by adding the project directory itself to INSTALLED_APPS. If you have a need for a project level startup.py, then this is the approach that should be taken. So - comments? Suggestions? Yours, Russ Magee %-) -- 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.
