Support for signal after settings have been read

[Mitar]

I would ask for support for a Django signal after settings have been read. The reason is that this would allow some post-processing just after the Django has been loaded, without having to add that code in settings file itself (which is bad practice and also prevents extensibility).

For example, mongoengine connection could be cleanly established in this way.

[Simon Charette]

Can you elaborate on the reasons this is needed for mongodbengine? Which settings have to be added? Are you referring to ​this?

[Mitar]

I am talking about ​MongoEngine. For connecting they ​propose to add connect call to settings. Something like:

MONGODB_DATABASE = 'database'

import mongo
mongoengine.connect(MONGODB_DATABASE)

The problem is that this does not allow me to override MONGODB_DATABASE in some other settings file. For example, I often use one development settings file and another production which includes everything from the first and overrides things for production. But with that approach this is not possible as mongoengine.connect is called too soon. And furthermore, it is not a clean design to call things from settings file.

MongoEngine is just one example. I believe this pattern could be used anywhere you want to do some additional preprocessing before letting Django do its work, but you want to have access to settings.

[Russell Keith-Magee]

This isn't a new suggestion -- e.g., see #13024.

However, it may not be obvious why this is a duplicate of #3591.

The underlying problem here is that Django doesn't have a clean 'startup' sequence. There's no place where you can put logic that you want to execute once when the stack is initialised.

This is also one of the reasons why a signal isn't the best solution for this problem. In order for a signal to be triggered, it needs to be registered; signal registrations need to happen once, when the stack is initialised. Therefore, there's a 'chicken and egg' problem with using a signal that triggers on stack startup.

In order to solve #3591 (currently referred to as the "App refactor") we need to introduce a clean startup sequence for apps. This will provide a reliable place to put stack startup logic.

[Mitar]

Thanks for the explanation.