On 05 Sep 2014, at 23:18, Carl Meyer <c...@oddbird.net> wrote: > On 09/05/2014 03:11 PM, Marc Tamlyn wrote: >> Yup, that works. The issue is that most users never explicitly call >> django.setup(), so they need to know how to modify manage.py and wsgi.py >> to do >> >> conf = MyProjectConfig() >> django.setup(conf) >> <something here> >> >> In the case of wsgi.py this isn't too obtuse, but django.setup() is here >> - >> https://github.com/django/django/blob/master/django/core/management/__init__.py#L310 >> for management commands. Not the easiest place to customise! > > 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.
But if a different config style is needed, we’d override it:
DJANGO_PROJECT = ‘mysite.project.foo’
Default style:
import django
class FooProject(django.SettingsProject):
DEBUG = False
bar = FooProject()
Flask style config:
import django
import foo
bar = foo.ConfigProject()
bar.config.update(
DEBUG=True,
SECRET_KEY=‘...',
)
Or ini/yaml style config:
import django
import foo
bar = foo.YamlProject('/path/to/config.yaml')
Whether we’d want to ship the latter two project style classes as part of
Django is a different question, I just think that offering a common API for
project configuration (via a “Project” base classes) may be a sane way to
slowly move away from the Django settings file via duck typing.
Alternatively we could have the project itself be the wsgi app but I’m
reluctant to go down that road given the past refactoring around wsgi.py that
basically resulted in not making Django projects WSGI apps themselves. I like
the fact that we separate configuration from the WSGI gateway, but maybe
projects like Flask and Pyramid have shown that to be a non-issue after all.
I’m on the fence.
So far my quick brain dump.. :)
Jannis
signature.asc
Description: Message signed with OpenPGP using GPGMail
