On Mon, Jun 7, 2010 at 5:38 PM, Chris <cp368...@ohio.edu> wrote:
> On Jun 7, 10:45 am, Alex Gaynor <alex.gay...@gmail.com> wrote:
>> On Mon, Jun 7, 2010 at 1:15 AM, Chris <cp368...@ohio.edu> wrote:
>> >> try:
>> >> from settings_local import *
>> >> except:
>> >> # It's ok to not have any local settings.
>> >> pass
>>
>> > This pattern is used by almost everybody it seems. Is there any reason
>> > why this pattern hasn't been adopted by "django-admin.py startproject"
>> > yet?
>>
>> For one thing I'd say because most *really* large projects realize
>> this is a really bad way of handling settings.
>
> Worse than one giant settings.py file?
>
>> From my experiences
>> I'd say it makes a lot of sense to invert the dependencies, localized
>> settings require the global defaults, not the reverse.
>
> The way I do it (and I'm assuming a lot of people do it this way too)
> is to have global settings tracked in their source control, while
> local_settings is something they have to write manually because it is
> untracked (due to having passwords and all). So it's way lore likely
> that the local settings file is missing instead of the global
> settings. Also, it really doesn't matter if one is more likely to be
> missing because both have to be present in order for the project to
> run. Does it really matter if the global or the local settings file
> raises the import error?
>
Having posted the first way, I can appreciate that Alex's technique
gives slightly more control to the person writing the per-instance
config, without some of the cruft. For instance, my 'settings imports
settings_local' technique looks like this:
try:
from settings_local import *
except:
# It's ok to not have any local settings.
pass
# Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists,
# so we can append any extra ones supplied in settings_local.py
if EXTRA_APPS:
INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS
where as if settings.py is the 'local' file, with it loading default
settings from settings_default.py, it could look like this:
from settings_default import *
INSTALLED_APPS = list(INSTALLED_APPS) + [
'some_app',
]
The project will always have default settings, so no need for a
try/except block, and we can directly manipulate settings without
having to pass around extra arguments, it's much neater.
OTOH, it works exactly the same once deployed :)
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
