How to manage django settings.py for Github, local, production

[surya]

Everyone talked about local, production settings.. 

try:

   from local_settings.py import *

except:

   # general settings.py 

my case needs three different settings: Github, local, production I have Django repo on github, and on pc (local). Now, need to push to another tree, the production server.

In our project, as its opensource, the master branch can't be directly pushed into Production server as it contains confidential settings.. For that I (admin of server) created a local branch to specifically contain production settings using local_settings.py.. The master is merged as into this branch as soon as we release new feature/ fix bug etc.. (any better way of handling. please tell me)

However, local_settings.py is included in .gitignore (remember, our master is on Github).. 

So, I need to edit .gitignore in local branch (containing production settings) and push to server..

As soon as I merge master into it..for adding new stable code, I need to update .gitignore (to track local_settings.py).. this is pathetic.. 

so.. i appreciate if you can provide a good working model!

[surya]

In simple words.. 

There is a file (local-settings.py) in a local branch, should be ignored while pushing in github, but should be pushed into server.. :p .

Hope this seems lot complex.. any simple ideas? (the less the manual work, the better.. ) 

[Alexey Kinyov]

Hi, Surya!

My practice is to have 'settings_template.py' in repository and
'settings.py' ignored, so 'settings.py' looks like:

from settings_template import *

# and here's confidential settings and other

There also may be many 'templates' for settings, like
'settings_dev.py', 'settings_production.py', but 'settings.py' is
always created on the host and never pushed to repo. And in addition
to that there may be an example file in repo, like
'settings.py.example'.


Regards,
Alex
///

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Branko Majic]

On Fri, 29 Mar 2013 00:40:12 -0700 (PDT)
surya <kastur...@gmail.com> wrote:

> In our project, as its opensource, the master branch can't be
> directly pushed into Production server as it contains confidential
> settings.. For that I (admin of server) created a local branch to
> specifically contain production settings using local_settings.py..
> The master is merged as into this branch as soon as we release new
> feature/ fix bug etc.. (any better way of handling. please tell me)

Well, one interesting concept I've see is from the Two Scoops of Django
(I join the minions on this group that recommend this book - probably
one of the best buys in my life) - the authors use separate
configuration files for production, test, development (even
per-developer settings), storing all of them in the repo, _but_ they
don't store any confidential data in those files.

Instead of that they use environment variables to make the passwords
available to user running the code, and then inside of "base"
settings.py they use a bit of Python code to read them and assign them
to appropriate variables.

There's probably a couple of variations on this as well - for example
storing path to file containing the password in environment variable,
and then reading from there etc.

Best regards

--
Branko Majic
Jabber: bra...@majic.rs
Please use only Free formats when sending attachments to me.

Бранко Мајић
Џабер: bra...@majic.rs
Молим вас да додатке шаљете искључиво у слободним форматима.

[Josh Cartmell]

You could set up a fabric file that handles the pushing. In our local
repo create a file called live_settings.py (which is ignored by git).
When fabric pushes to the production server tell it to copy
live_settings.py to local_settings.py on the production server.