[patch] Add ability to perform pre-runtime setup before executing code

[Ben Slavin]

Django should allow developers to elegantly inject functionality prior to general code execution.

This is useful if something needs to happen before models are loaded (register as a class_prepared listener). Malcolm indicated that he is aware of other cases where this could be useful.

This issue has been discussed briefly on django-users. ​http://groups.google.com/group/django-users/browse_thread/thread/2f395d5b50086aea/

[Ben Slavin]

First-pass implementation of this functionality. Lacks documentation.

[Ben Slavin]

I have attached a first-pass at solving this. It currently lacks documentation.

One side-effect (bonus?) of the implementation method I chose fixes the ModPython handler to no longer reprocess settings.MIDDLEWARE_CLASSES on every request. I don't think that this will have any negative impact (in fact it should speed things up), but I wanted to mention it.

[Ben Slavin]

A few changes... described below.

[Ben Slavin]

Summary of changes

django/conf/global_settings.py

• Added RUNTIME_SETUP_FUNCTIONS (default empty).

django/core/handlers/wsgi.py

• Locking and middleware loading calls moved to HandlerState.ensure_state.

django/core/handlers/base.py

• Added HandlerState class and handler_state global.
• HandlerState handles loading middleware and runtime environment setup (ensure_state method).
• Uses locking semantics to ensure things are only performed once per-process.

django/core/handlers/modpython.py

• Removed explicit middleware loading, moved to ensure_state.

django/core/management/commands/shell.py

• Perform runtime setup for shell command.

django/utils/setup.py

• Defined setup_runtime function to run settings.RUNTIME_SETUP_FUNCTIONS.

django/test/client.py

• Removed explicit middleware loading, moved to ensure_state.

[Jacob]

Can you explain what the use case is here? I understand what you'd like to add, but not why you'd like to add it.

[Ben Slavin]

Replying to jacob:

Can you explain what the use case is here? I understand what you'd like to add, but not why you'd like to add it.

The primary reason I'm looking to do this is to register listeners of the class_prepared signal. We have a few things that we need to do or add to all models and there's no good way to do this without the ability to listen for class_prepared. Unfortunately, the signal is called so early in the life of a Django process that we can't reliably register a listener before the models are created.

I'd imagine that there are other things people might want to do to the environment before anything is run, but none immediately come to mind. Malcolm seemed to have a few other ideas ​when this was discussed on django-users, but didn't explicitly mention what they were.

[Ben Slavin]

Reassigned to Malcolm at his request.

[Malcolm Tredinnick]

Pushing to after 1.0 now. It's a feature addition that could potentially cause unexpected side-effects.

[(none)]

Milestone post-1.0 deleted

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

The app-loading refactor clarified Django's start-up sequence and a solution for ​registering class_prepared receivers was documented.