[TIP] Testing programs that are intended to be distributed in public repos but which need non-public information in order to work

[Tom Davis]

On Aug 27, 2011, at 3:01 AM, Doug Latornell <doug at sadahome.ca> wrote:

> On Fri, Aug 26, 2011 at 10:46 PM, Laura Creighton <lac at openend.se> wrote:
>> I'm writing an app that I'm hosting publicly on bitbucket.  In order for it
>> to work, I need to use my secret password to get into the postgresql
>> database at the site I am developing this on, and my PayPal developer
>> account id and password, and things of that nature.  But I don't want
>> to share this information with the world.
>> 
>> Currently, all this information lives in one file, called settings.py .
>> I've asked hg not to track this file.  Instead I have a file called
>> settings.notreal.py, which is tracked and is a copy of settings.py
>> with the sensitive data replaced with dummy data.  But this means that
>> I, and anybody else who wants to hack on the thing needs to know
>> that if they make any changes to settings.py they have to make them
>> to settings.notreal.py, too.  A trivial python script can generate
>> one from the other, the problem is in remembering to do so before you
>> make your commit, etc. so that your commit messages i.e 'fix for failing test
>> ABC' aren't complete lies, because they leave out the actual fix.
>> 
>> This must be a common situation, with a well understood solution, but
>> my Google-fu apparantly isn't up to finding the correct keywords to
>> search for.  Maybe the whole approach of having 2 files is wrong, and
>> that is why I am not finding anything.  So what do people do?  And
>> what url should I read to figure out how to do it too?
> 
> I use a Mercurial queue to patch the real credentials into a tracked
> file that has all of their values set to None. Mercurial won't let you
> push while a queue patch is applied unless you use --force, so  the
> likelihood of accidentally pushing real credential values is greatly
> reduced. The downside is that you have to juggle your patch queue if
> you use mq for anything else in your workflow.
> 
> Doug

Maybe I'm missing something obvious that makes this a non-starter, but the standard convention in Django is to have settings.py and local_settings.py, where the former imports everything from the latter in a try/except at the bottom of the module. This way, the local settings override the normal settings values if any overlap and not having the file at all doesn't hurt anything. Add local_settings.py to .hgignore and that's that. The rest of these examples seem way more complex than strictly necessary, unless I am missing something that makes this not viable.

> 
>> 
>> Laura
>> 
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
>> 
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python