2010/1/20 Jacob Kaplan-Moss <ja...@jacobian.org>:
> On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant <l.plant...@cantab.net> wrote:
>> I don't understand how avoiding the settings.py mechanism will produce
>> *more* flexibility.
>
> The problem -- at least as I see it -- is that of a intertwingulment
> of "application" settings with "ops" settings.
>
> As organizations get larger, roles stratify more. Thus you end up with
> a pretty big gulf between the ops team and the application developers.
> In these environments, application developers probably shouldn't be
> messing with things like the `DATABASE_*` settings -- in some
> organizations its even a breach of policy for the developers to *know*
> the database password!
In the past I've used code like the following in settings files:
# we're going to allow overriding of settings via a yml file.
# This makes live nicer for anyone managing the box
# and means settings can be overloaded without redeploying the site
SETTINGS_OVERIDE = "/etc/$(project).yml"
try:
file = open(SETTINGS_OVERIDE)
for key, value in yaml.load(file).items():
globals()[key]=value
except:
# we don't always have the file around or need the setting
# defined so best to be quite if things go wrong
pass
You can also make this more limited, by allowing only the overriding
certain settings. You can then use tools like puppet on the ops side
to push config files in to /etc (or wherever suites you system).
Example here
http://morethanseven.net/2009/02/15/let-you-sys-admin-override-your-django-settings/
This pattern is also used in my project templates paster stuff:
http://github.com/garethr/django-project-templates and
http://pypi.python.org/pypi/django-project-templates/
>
> OTOH, ops types don't know what the heck to do with `INSTALLED_APPS`...
>
> And then there's middleware: some middleware (caching, etags) might
> need to be controlled by ops; some by apps.
>
> Obviously you can *do* this with Django, and I'd argue it's not
> particularly hard. Still, it's something that bigger orgs have to
> figure out themselves, and that can be a barrier to adoption.
>
> The enterprisey world solves this with standards like WAR and servers
> like Glassfish: if I'm an application developer, all I need to do to
> deploy is somehow produce a WAR. And if I'm a ops person, I just take
> that WAR and slap it into Glassfish. It's rarely that easy in
> practice, of course, but the execs making the tech decisions don't
> know that.
>
> Jacob
>
> --
> 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.
>
>
>
>
--
Gareth Rushgrove
Web Geek
morethanseven.net
garethrushgrove.com
--
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.
