On 09/06/2014 03:10 AM, Jannis Leidel wrote: >> Yes, that approach would definitely require some thinking (which I >> haven't fully done yet) about how best to get a custom >> ProjectConfig inserted into both the wsgi.py and manage.py >> entry-points. > > Just a quick drive-by comment: ZOMG YES PLEASE. > > I also could see a default project class that uses a global settings > module that we’d provide for backwards compatibility, but that could > eventually be replaced by something that follows other configuration > styles. > > As to how to normalise the API between wsgi.py and manage.py I think > environment variables have worked well for not having to reach too > far into the WSGI and management code. So I suggest to introduce a > new env var called DJANGO_PROJECT with the dotted path to the Django > project object (or to something that quacks like one at least) that > defaults to ‘django.default_project’ or similar that does the > DJANGO_SETTINGS_MODULE inspection for django.conf.settings.
I think we should avoid requiring a new environment variable, if possible, otherwise we'd just be repeating the unfortunate "you can't import this module because you haven't set DJANGO_SETTINGS_MODULE" type of error, and adding a new instance of "look up some class by dotted string", which is the sort of not-quite-Pythonic stuff that this proposal is aiming to avoid. Instead, I'd envision just providing an alternative new "run management command" API that did not call django.setup() for you, but expected you to have already called it. Then the stock manage.py could be updated to use that new API after calling django.setup() explicitly, and then it would be possible to pass in a custom ProjectConfig as an argument to django.setup() just by modifying your manage.py. At this point, wsgi.py and manage.py would not be special in any way; they would just be typical examples of the general rule that "if you want to write a script that uses Django, you should call django.setup() before doing anything else." All of this wouldn't really fix the circular-import issues we already have with importing stuff in settings, though. If you want to configure your ProjectConfig in code you'd need to import some classes (e.g. middleware), and you'd still need to be careful that that doesn't involve importing a module that has an import-time dependency on global config. So it would remain valuable to reduce import-time dependencies on the global config. In a sense, what a proposal like this would achieve is to merge the two current separate questions "are settings configured?" and "is the app cache ready?" into a single "is Django setup?". This is conceptually simpler, but I think it remains an open question how much practical improvement it achieves. Carl
signature.asc
Description: OpenPGP digital signature
