It does slight more than that - settings configured and settings used are
two very different things at present - to use our canonical example
MIDDLEWARE_CLASSES is *configured* by checking that it's a tuple of strings
and is there. It's used/setup much later when those classes get imported
and initialised. It opens up more potential to mess around with this second
step - freeing MIDDLEWARE_CLASSES from being a tuple of dotted paths to
being, well, a set of classes. Circular imports are an issue, but IMO it
wouldn't be *that* awful to have the ProjectConfig file recommended that
you just put the imports in the customised methods all the time to be on
the safe side.
e.g.
MyProjectConfig(ProjectConfig):
def get_middleware_classes(self):
from thirdparty.middleware import ConfigurableMiddleware
classes = super().get_middleware_classes()
config = {...}
classes.append(ConfigurableMiddleware(**config)
return classes
Obviously you could not call the super at all (which inspects the setting),
do all the importing and initialisation of the default middleware yourself
and BOOM no settings.
[There are some technical issues to solve here to do with how you actually
access the built middleware classes from code, especially regarding
potential for changing them at runtime in tests]
Hypthetical: What we may find in this refactoring is that some of the
places Django currently dies if the settings are not configured can be
relaxed somewhat to not-at-import-time, so we may be able to avoid some of
this.
On 6 September 2014 22:04, Carl Meyer <c...@oddbird.net> wrote:
> 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
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMwjO1H9RWufw69VtkOhR-ZoUuPrfoOdOsrQN%2B-R8TiVCpO5LQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
