3 ms·

why not just use multiple layered settings files? in .... settings.py put from local_settings.py import * at the bottom then have local_settings.dev.py loc

why not just use multiple layered settings files? in .... settings.py put from local_settings.py import * at the bottom then have local_settings.dev.py local_settings.prod.py local_settings.release.py that you copy to local_settings.py depending on the situation.

singold 14y ago
Or better, have a folder called local_settings with an __init__.py empty file in (making it a package) and then just drop your custom settings there
- misiti3780 14y ago
  something like this: http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-settings-py/ http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...
natrius 14y ago
It's less painful if you invert those files. For example, create settings/defaults.py, then in settings/dev.py, import * from defaults and override what you need to. Set DJANGO_SETTINGS_MODULE appropriately. You'll thank me when you're adding dev-only apps, middlewares, etc. and can say INSTALLED_APPS = INSTALLED_APPS + [...].
- antihero 14y ago
  This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.
antihero 14y ago
Don't do this, do: * settings/base.py * settings/production.py * settings/local.py settings/base would have your "common" settings, settings/local.py could be as simple as from .settings.base import
teilo 14y ago
I already do that. I have a common_settings.py, a dev_settings.py, and a local_settings.py. That's not really the use case I am speaking of. First, it still makes you put all application config into a single config file (considering that even if you "inherit" settings from a common file, it's 100% equivalent to having one big settings file). Second, you cannot change these settings in-app. They are hard-coded.
- mvc 14y ago
  If it's not already supported, it shouldn't be difficult to make a Django process respond to the HUP signal by reloading it's settings. That's how Postgres does it.

singold 14y ago

Or better, have a folder called local_settings with an __init__.py empty file in (making it a package) and then just drop your custom settings there

misiti3780 14y ago
something like this: http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-settings-py/ http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...

natrius 14y ago

It's less painful if you invert those files. For example, create settings/defaults.py, then in settings/dev.py, import * from defaults and override what you need to. Set DJANGO_SETTINGS_MODULE appropriately. You'll thank me when you're adding dev-only apps, middlewares, etc. and can say INSTALLED_APPS = INSTALLED_APPS + [...].

antihero 14y ago
This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.

antihero 14y ago

Don't do this, do: * settings/base.py * settings/production.py * settings/local.py settings/base would have your "common" settings, settings/local.py could be as simple as from .settings.base import

teilo 14y ago

I already do that. I have a common_settings.py, a dev_settings.py, and a local_settings.py. That's not really the use case I am speaking of. First, it still makes you put all application config into a single config file (considering that even if you "inherit" settings from a common file, it's 100% equivalent to having one big settings file). Second, you cannot change these settings in-app. They are hard-coded.

mvc 14y ago
If it's not already supported, it shouldn't be difficult to make a Django process respond to the HUP signal by reloading it's settings. That's how Postgres does it.