I've used the execfile approach in my settings.py like so:
# Include any local settings that override the defaults.
try:
execfile('local_settings.py')
# Hack so that the autoreload will detect changes to local_settings.py.
class dummymodule(str):
__file__ = property(lambda self: self)
sys.modules['local_settings'] = dummymodule('local_settings.py')
except IOError:
pass
The advantage of execfile over an import is that the local_settings is
executed within the settings.py namespace, so your local_settings.py can
read or modify default/global settings (add its own middleware, installed
apps, etc).
That all being said, I think it's best left to each project or team or
developer to decide how to make settings.py work for them and hide any
sensitive information.
On Tue, Mar 22, 2011 at 7:09 PM, Matt Robenolt <youdontevenk...@gmail.com>wrote:
> That's just interesting. I've never seen the use of `execfile()` before. We
> use a devsettings.py and use it to override an individual server or local
> settings, and then on the live/deployed server, no devsettings.py is even
> included. Hence the try...except wrapped around it. It's a nice little
> pattern that gets us by, but yes, things like this do show that there needs
> to be one overall "recommended" method for maintaining separate settings on
> a per server/environment basis.
>
> On Mar 22, 2011, at 7:05 PM, Ian Kelly wrote:
>
> > On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
> > <youdontevenk...@gmail.com> wrote:
> >> Why not just do an import for your custom settings?
> >>
> >> try:
> >> from site_settings import *
> >> except ImportError:
> >> pass
> >
> > No particularly compelling reason that I know of, the import machinery
> > is just unnecessary in this case. The site_settings.py is viewed as
> > an extension of the settings.py, so it doesn't need to be loaded as a
> > module in its own right. And for the same reason we know exactly
> > where we expect the file to be, so there's no need to consult
> > sys.path.
> >
> > I suppose it just comes down to a matter of taste.
> >
> > Cheers,
> > Ian
> >
> > --
> > 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.
> >
>
> --
> 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.
>
>
--
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.
