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

[Ben Finney]

Michael Foord <michael at voidspace.org.uk> writes:

> On 27/08/2011 06:46, Laura Creighton 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.
>
> I usually just put [the configuration settings] in a separate file
> that is "ignored" by mercurial (so it can't accidentally get checked
> in).
>
> I usually put a template of the file in the repo, for people to easily
> create the file themselves with their credentials - along with a
> helpful error message if the file is missing when writing tests.

Yes, these are the practices I take with configuration files for
VCS-tracked programs: track the program in VCS, track a template of the
configuration file in VCS (and release it with the program), and
specifically instruct the VCS to ignore the real configuration file.

Further, I make sure the configuration is non-executable data: settings
to be read, rather than code to be run.

Either of ‘configparser’ or ‘yaml’ Python modules are good for
non-executable configuration data for programs.

(JSON is a data serialisation format and isn't good for user-editable
configuration settings – it has no allowance for comments, among other
shortcomings.)

-- 
 \           “The long-term solution to mountains of waste is not more |
  `\      landfill sites but fewer shopping centres.” —Clive Hamilton, |
_o__)                                                _Affluenza_, 2005 |
Ben Finney