Here is a sneak peak into the application settings file format we use at bit.ly.
The idea behind this settings file format, is that it should completely incapsulate all of the “where” information. The information about “where” an application is running, “where” data is stored, and “where” it connects to for remote resources should only exist in this file. (it can also be an effective spot to put default values that are set once and used consistently for each environment.)
One popular approach to settings files is to make a single config file, and run applications with --config-file flags pointed to different files depending on the location. The issue I have with that approach is that time and time again when new features are added, new settings only get added to the development config file, and not the production config file. I have found that using a --environment flag and putting the settings for all environments in a single file resolves that issue.
Specifying settings in a python file gives some useful flexibility as well. For example, we use a randomize wrapper that at returns a random setting each time it is requested. This makes for a very easy, simple and efficient way to distribute load across several remote endpoints.