As mentioned earlier, Django projects are essentially collections of regular Python modules. These are managed using a settings file. We can have more than one settings file for any project—separate production and a development settings file, for example. Django settings files are also code, which adds even greater flexibility. Using import statements, for example, we can include a standard set of Django settings in every project and simply override the ones we need to change.

When using version control software, it's helpful to keep many different settings files. These files can be organized by developer, by server name, or by code branch. Keeping multiple settings files simplifies deployment and testing. A settings file for each test server or individual developer reduces confusion and prevents breakage as developers create and integrate new apps. However, it retains the convenience and safety of version control. Trying to maintain a large project with multiple developers and a single settings file is a recipe for disaster.

With multiple settings files floating around, how does Django know which one to use? In the command line environment for running interactive Python shells or scripts, this is controlled using an environment variable called DJANGO_SETTINGS_MODULE. Once your settings are in place, you can quickly switch back and forth between them by modifying this environment variable. For example:

# switch to our testing settings and run a Django interactive shell
$ export DJANGO_SETTINGS_MODULE=myproject.settings_testing
$ django-admin.py shell
# switch back to our production settings
$ export DJANGO_SETTINGS_MODULE=myproject.settings_production

A convenient alternative to the preceding manual process is to use the settings flag of django-admin.py, which will adjust the settings module appropriately. Switching to production settings looks like this:

$ django-admin.py–-settings myproject.settings_production

A simple set of shell scripts can automate the use of several settings files. The following shell script wraps Django's django-admin.py and sets a specific settings module. This way we can run our project from the command line with a single simple command, like this.

#!/bin/sh
# myproject_dev - a shell script to run myproject in development mode
export DJANGO_SETTINGS_MODULE=myproject.settings_dev
django-admin.py $@ 

For server deployments, the settings file is specified as part of the server configuration. Sometimes this involves changing the environment variable from an Apache config file (SetEnv DJANGO_SETTINGS_MODULEmyproject.settings). On mod_wsgi setups, it usually means modifying the Web Server Gateway Interface (WSGI) script. We will explore these configuration techniques in Chapter 10, Deployment and Maintenance Strategies.

The other core piece of all Django projects is the root URLs file. Again, this is just a code that defines a set of URL patterns using regular expressions. We can include multiple versions (production vs. development) for our project and use normal Python flow-control to make adjustments such as adding special URL patterns when our project has the DEBUG setting turned on.

For larger Django projects, multiple settings and URL files can quickly get out of hand. As a result it is a smart practice to keep project files, such as settings and root URL configurations, completely separate from app code. Structuring your project and app libraries is often dependent on personal taste or company standards, but keeping a modular and loosely-coupled mindset is always beneficial.