Hello Aymeric,
regarding django.setup() idempotence I continued discussion in the PR.
Regarding django.setup() tweakability, the generic need is simply to have a hook, somewhere for users to put early init code, regardless of the way django is launched. Code that needs to execute this early are mostly (if not all) monkey-patching the environnement, a little like a LD_PRELOAD logic python-style.
This can be:
- for (of course) the init of django-compat-patcher
- early tweaking of some process aspects likes socket timeouts (they broke for me when used along with mutiprocessing, but several years ago)
- possibly setup of specific test scaffolding, for which late mock()-style things aren't enough (I have no precise scenario in mind for this one, even though I know we did suffer with a Jpype bridge to a java LDAP client, which required tons of care to not break, including being initialized rather early along with process signal handlers)
Without a hook built into django, users that need such early setup have to duplicate their efforts for each way Django can be launched, and they must call their patching code in manage.py, in the wsgi file, in their custom scripts, and in their specific runners likes pytest-django (this last case is quite uneasy to handle at the moment, due to its very early setup of Django).
I'm afraid I can't provide much code to help the pondering; simply, without builtin hook, the user has to battle to ensure the kind of lines like the following are always executed before django.setup(). If Django provides a hook, it's so much less to worry about.
from psycogreen.gevent import patch_psycopg
patch_psycopg()
There are surely lots of ways to provide such a hook, via new settings, or new environment variables, or modules following precise naming conventions that django would systematically try to import... I have no idea how exactly my approach is rated amongst them.
As for alternatives to these early setup hooks, I'm alas clueless...
regards,
Pakal