Structured settings b

[vernondcole]

This is a clean up and re-submission of my former structured settings pull request. It includes all patches to settings.py current as of this date (21 Sept)

[vernondcole]

There are two advantages to a structured settings module.
First, it makes switching between roles (such as test and production) a matter of a single environment variable (DJANGO_SETTINGS_MODULE) which is easily set in virtualenv, or by using the --settings= switch in manage.py.

Second, it more readily isolates important application-wide modifications (e.g. the order of applications in INSTALLED_APPS) from site specific details (the use of a different test database for each programmer.)

DJANGO_SETTINGS_MODULE (or the selection of --settings=) specifies a detail settings file. Near the top, that file imports a higher level settings file, then overrides any appropriate settings. The global settings for the project will be contained in settings/base.py -- which should not need to be modified for different installations. Installation-wide modifications can be isolated in intermediate-level settings files.

[vernondcole]

The Travis failure is now nothing to do with my code. In other words, the test using structured settings works exactly like the test using traditional settings -- which is really the only test I know of.
Can the kml export test be fixed (or skipped?)

FAIL: test_kml_export (main.tests.test_kml_export.TestKMLExport)

---

Traceback (most recent call last):

File "/home/travis/build/modilabs/formhub/main/tests/test_kml_export.py", line 36, in test_kml_export

self.assertMultiLineEqual(response.content, expected_content.strip())

AssertionError: '\n<kml xmlns="http://earth.google.com/kml [truncated]... != '\n<kml xmlns="http://earth.google.com/kml [truncated]...

[vernondcole]

My mistake: but my error actually proved that the structured settings are working ... the line causing the KML test to fail was part of the test environment settings in the intermediate setting file. I had inserted a debug aid in TEMPLATE_STRING_IF_INVALID. This had its intended effect in locating an invalid template string in the KML test -- which the test script was programmed to have ignored.

[vernondcole]

Look this over, but hold off on merging it. I have received some additional input from django developers and think there may be a somewhat better way to do this.
Stand by for updates.

[dorey]

Hi @vernondcole . I agree that the way that the settings are organized could be improved. Curious how you came up with putting the settings in "preset" directory. Is this something that you've seen used in other django projects?

[ukanga]

Hi @vernondcole, is it ok now if we have a look at this and probably update it before we merge? You had mentioned you were waiting on some feedback before we can go ahead.

[vernondcole]

Sorry -- I got sidelined on another project for a while. Yes, I think this is the way it should look, now. The "preset" directory is my invention to answer the objections presented by feedback from django developers. This design can be used either with the traditional local_settings pattern, with structured settings, or with the new 12-factor methodology which seems to be the present rage. I have included an example of that and of each major database engines. I am planning to submit a version of this as an enhancement for django 1.7. (Perhaps they may even accept it.)

[vernondcole]

This updates the pull request by merging recent changes in master.
It picks up the changes to settings.py.
It moves the new local_settings.py.travis file into a preset, with modification to .travis.yml to use the preset.
It restores the attempt to import local_settings.py, so that installations depending on it will not be surprised.