Best practices for open sourcing a Django project?

[Joshua Russo]

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?

[Cal Leeming [Simplicity Media Ltd]]

You could just include the necessary info in the README, or make a wrapper script that does it for them - although I tend to stick with READMEs where possible as they consume less time.

If the code is coming straight out of production, there's a few tips I'd recommended;

* Ensure that you test the code outside of the production environment against a test project, and make sure it works as expected.

* Triple check that you haven't left any private info in the code

* Provide a (reasonable) amount of documentation

Personally, I tend to opt for this license;

http://en.wikipedia.org/wiki/WTFPL

There are many places you can put your code (GitHub, my most favourite), and others such as BitBucket and Google Code - again it's down to personal preference.

Here is an example of a project I open sourced a while back... at the time I thought it was done well, but I later realised it needed a serious amount of re-writing and documentation - which I still haven't got around to doing;

https://github.com/foxx/django-cutemodel

Others may be able to offer a bit more advice, but the above is a head start at least!

Hope this helps!

Cal

On Sun, Oct 14, 2012 at 8:47 PM, Joshua Russo <josh.r...@gmail.com> 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?

--
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/-/LJU31pYrcXgJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Joshua Russo]

It sounds like you're saying that the open sourced project should be different from the production project. Am I reading that right?

[Avraham Serour]

I think you should include the config file, but with example parameters and comments, point out in the readme that there are some basic configuration to be done

[CLIFFORD ILKAY]

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

[Cal Leeming [Simplicity Media Ltd]]

Sorry, yes.

Personally whenever I have taken code out of production, I've created a small example project and then placed the code within it, and created a scenario where the functionality can be used tested.

This is why open source code sometimes isn't very good quality, it can be a huge time sink :/

Alternatively, depending on the size of the project, you could just do a code dump and a blog article about it - but obviously this might not attract as many people to use it.

Cal

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/6nucbxbFRF8J.

[Isuru 2eisuru]

I think best option is project hosting system like github or bitbucket. Bitbucket allow private hosting too. And version control is attached to it.

[Joshua Russo]

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

[Mike Dewhirst]

On 15/10/2012 6:47am, 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?

Although best practice seems to be separate local settings files I
prefer the same settings.py in both development and production. The big
problem of course is that sensitive information might end up in the
repository. And I haven't even considered open sourcing.

My solution is a tiny script called getcreds[1] which gets all the
necessary sensitive info whenever/wherever it is needed. I'm comfortable
that long in the future nothing sensitive was ever in the repo. That
includes certificate keys, passwords, userids, email addresses - anything.

I keep a private directory in which all my sensitive creds are kept in
plain text files with each item on a separate line. I adopt a personal
convention of userid, password, ip-address, port, etc etc. But it
doesn't matter because getcreds returns a list and creds[3] or creds[4]
can mean anything you want[2] in your seetings.

Mike

[1]
# -*- coding: utf-8 -*-
def getcreds(fname, credsdir='/var/creds/xxxx'):
""" Return a list of userid and password and perhaps other data.
make sure there are a few empty lines at the end of fname to avoid
keyerrors
"""
creds = []
fname = '%s/%s' % (credsdir, fname)
with open(fname, 'r') as f:
for line in f:
creds.append(line.strip())
return creds

[2]
#excerpt from settings ...
dbhost = getcreds.getcreds('db.host')
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': PROJECT,
'USER': dbhost[0],
'PASSWORD': dbhost[1],
'HOST': dbhost[2],
'PORT': dbhost[3],

>
> 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?
>