For the record, the "from settings_default..." method is exactly how my team's largest projects are deployed. It works just fine for us!
Even more fun (though bordering on too tricky) is converting INSTALLED_APPS to a set instead of a list so you can add *or* subtract items. This whole argument has gotten silly, though, since Russ (rightly) rejected it about 20 posts back ;-) All the best, - Gabriel On Jun 7, 9:47 am, Tom Evans <[email protected]> wrote: > On Mon, Jun 7, 2010 at 5:38 PM, Chris <[email protected]> wrote: > > On Jun 7, 10:45 am, Alex Gaynor <[email protected]> wrote: > >> On Mon, Jun 7, 2010 at 1:15 AM, Chris <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
