What is the difference between privately tracking a shell file and a Python config file? Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)
-----Original Message----- From: Carl Meyer <[email protected]> Sender: [email protected] Date: Fri, 27 Sep 2013 10:28:00 To: <[email protected]> Reply-To: [email protected] Subject: Re: Add strutctured settings module to django 1.7? Hi Tom, On 09/27/2013 09:51 AM, Tom Evans wrote: > On Thu, Sep 26, 2013 at 2:21 PM, Andres Osinski > <[email protected]> wrote: >> Honestly, I find the idea of *not* using a settings file to be inconvenient, >> and the notion of using environment variables for doing anything aside from >> pointing to a settings file to be pretty disgusting. > > +1 > > The idea that before you start working on a project you need to infer > and set the 50 or so environment variables required is anathema to me. FWIW, this is a straw man; I don't believe anyone is doing that. I've recently switched to handling more configuration via env vars, and what it actually looks like in my case is a normal (single) settings file with a lot of settings values optionally read from the environment, with defaults if the env var is not present. Typically a dev environment can be run with zero env vars, a production environment will have a few (secret key, database url, sentry dsn, api keys, etc). > The most important concern is that these settings are not part of your > code, they are part of your configuration. Consistency of > configuration is one of the most important things in DevOps, and so > IMHO the most important thing in your project is tracking and managing > the changes in your configuration. > > To me, that means one thing. Configuration files live in VCS > repositories - this is the only way to track changes to your > configuration, to validate that there are no unexpected changes to the > file. Totally agreed, but I'm often in a situation where its not possible for the primary codebase to be kept appropriately private, meaning there needs to be some solution for injecting "secret" site-specific configuration into a production instance. The only two solutions I've used for that are local_settings.py and env vars, and having used both I'm much happier with env vars. (Even with env vars, I track them in a simple shell file in a separate, private deployment VCS repo.) Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
