-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi TiNo,
On 10/11/2011 06:10 AM, TiNo wrote:
> Definitely +1, as this has bitten me far too often. It would be nice
> however to also depend less on the ('hacky', as Glyph also noted)
> DJANGO_SETTINGS_MODULE environment variable. We shouldn't need an env
> variable to run a python website, and it certaintly shouldn't screw up
> settings loading when set accidently.
I'd certainly like to get rid of DJANGO_SETTINGS_MODULE in the long run,
but I don't see how we can do so without also getting rid of
process-global settings, and that's a much bigger project and patch, far
out of scope for what I'm attempting here.
As long as we have process-global settings, we need an explicit way for
users to specify which settings module they want to use, that is
possible to provide across a variety of different ways of invoking a
process (including e.g. having it implicitly invoked by mod_wsgi, in
which case some other options, like command-line parameters, are not
available). Having multiple settings modules available and picking one
for a given invocation is a feature, and an important one for many
people. If you have a proposal for a better way to do that than
DJANGO_SETTINGS_MODULE, that can be implemented in a
backwards-compatible way, we can certainly discuss it - but it doesn't
need to hold up this patch.
The new proposed setup_settings
> function accepts a path, but listens to the env variable first, and if
> that is not set it it wil still try to load 'settings'. Why not listen
> to the path that is provided so I can pass 'mysite.settings.production'
> for example? And if it's not provided, listen to DJANGO_SETTINGS_MODULE
> for backwards compatibility.
The "setup_settings" function is not a part of my proposed patch for
#15372 (cleaning up sys.path handling), it's part of the current patch
for #16360 (wsgi entrypoint), and it's precisely that part of the latter
patch which I expect to modify once #15372 is fixed.
Once I'm done with that patch, I don't think the setup_settings function
will be needed anymore (as it's basically a wrapper around
setup_environ, which will be deprecated). Instead, I expect wsgi.py will
simply contain a line very similar to what is currently in manage.py,
"os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')".
This is much simpler and more explicit than setup_settings.
This still gives DJANGO_SETTINGS_MODULE priority, and just sets a
fallback value - I don't think we can change that in the default
manage.py or wsgi.py, without breaking the ability for people to
override using DJANGO_SETTINGS_MODULE if they want, which is the
established pattern. However, the advantage of it being explicit is that
you can easily change the behavior if you want. If you want the
environment variable ignored, you can change that line to
"os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'" in your
project, and then Django will always use "mysite.settings", regardless
of the environment variable's value.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYhIACgkQ8W4rlRKtE2d9xACglQHuQsuqk2DCUzWJVILTuv56
C84AoLRFUE4Z4hCwQxbGQa1VfUN5tdPh
=Y4O5
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
