Clifford, I have actually done this but the local settings files were
merely used to override the production values. I think I like this way
better for handling things like the database and the various path settings,
though I'm not sure I will completely abandon the override mechanism either.
Thanks for the idea
On Sunday, October 14, 2012 4:56:59 PM UTC-4, CLIFFORD ILKAY wrote:
>
> On 10/14/2012 03:47 PM, Joshua Russo wrote:
> > I have project that I have been working and I was contemplating open
> > sourcing it but I ran into a little hang up. How to handle the
> > database authentication. The settings file obviously needs to be
> > included but I don't want to advertise the production database login.
> > How is this generally handled?
> >
> > Also, are there procedures that need to be followed to "properly" open
> > source a project, or is it really just choosing a licence and dubbing
> > it so?
>
> Hi Joshua,
>
> You would have the same issue if you have a staging process where you go
> from development, testing, and production. We handle that by having a
> local_config.py that is not checked into the Mercurial repo. At the top
> of settings.py, we have code that looks like this:
>
> import local_settings as LOCAL_SETTINGS
>
> ######### The following variables are defined in local_settings.py
> ##############
>
> DEBUG = LOCAL_SETTINGS.DEBUG
> ADMINS = LOCAL_SETTINGS.ADMINS
>
> DATABASES = {
> 'default': {
> 'ENGINE': LOCAL_SETTINGS.DATABASES['default']['ENGINE'],
> 'NAME': LOCAL_SETTINGS.DATABASES['default']['NAME'],
> 'USER': LOCAL_SETTINGS.DATABASES['default']['USER'],
> 'PASSWORD': LOCAL_SETTINGS.DATABASES['default']['PASSWORD'],
> 'HOST': LOCAL_SETTINGS.DATABASES['default']['HOST'],
> 'PORT': LOCAL_SETTINGS.DATABASES['default']['PORT'],
> }
> }
>
> TIME_ZONE = LOCAL_SETTINGS.TIME_ZONE
> SECRET_KEY = LOCAL_SETTINGS.SECRET_KEY
>
> DEFAULT_FROM_EMAIL = LOCAL_SETTINGS.DEFAULT_FROM_EMAIL
> EMAIL_HOST = LOCAL_SETTINGS.EMAIL_HOST
> EMAIL_PORT = LOCAL_SETTINGS.EMAIL_PORT
> EMAIL_HOST_USER = LOCAL_SETTINGS.EMAIL_HOST_USER
> EMAIL_HOST_PASSWORD = LOCAL_SETTINGS.EMAIL_HOST_PASSWORD
> EMAIL_USE_TLS = LOCAL_SETTINGS.EMAIL_USE_TLS
>
> CONTACT_EMAIL = LOCAL_SETTINGS.CONTACT_EMAIL
>
> INTERNAL_IPS = LOCAL_SETTINGS.INTERNAL_IPS
>
> ######### End of variables defined in local_settings.py ##############
>
> local_settings.py can vary from instance of the application to another
> and those sensitive things like passwords are never kept under revision
> control. settings.py is consistent regardless of whether it's a
> development, testing, or production deployment. If you find yourself
> having to change things in settings.py if you deploy onto another
> server, chances are it should be factored out into local_settings.py and
> imported into settings.py as above.
>
> --
> Regards,
>
> Clifford Ilkay
> Dinamis
> 1419-3230 Yonge St.
> Toronto, ON
> Canada M4N 3P6
>
> <http://dinamis.com>
> +1 416-410-3326
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/E1soXgwrEnoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
