Как Вы настраиваете Django для простой разработки и развертывания?

Обновление: django-конфигурации были выпущены, который является, вероятно, более оптимальным вариантом для большинства людей, чем выполнение его вручную.

, Если Вы предпочли бы делать вещи вручную, мой более ранний ответ все еще применяется:

у меня есть несколько файлов настроек.

• settings_local.py - определенная для хоста конфигурация, такая как имя базы данных, пути к файлам, и т.д.
• settings_development.py - конфигурация, используемая для разработки, например, DEBUG = True.
• settings_production.py - конфигурация, используемая для производства, например, SERVER_EMAIL.

я связываю их все вместе с settings.py файл, который во-первых импортирует settings_local.py, и затем один из других двух. Это решает, чтобы загрузиться двумя настройками в settings_local.py - DEVELOPMENT_HOSTS и PRODUCTION_HOSTS. settings.py вызовы platform.node() для нахождения имени узла машины это работает, и затем ищет то имя узла в списках и загружает второй файл настроек, в зависимости от которого списка это находит имя узла в.

Тот путь, единственная вещь, о которой действительно необходимо волноваться, в курсе settings_local.py файл с определенной для хоста конфигурацией, и все остальное обрабатывается автоматически.

Выезд пример здесь .

Лично, я использую единственный settings.py для проекта, у меня просто есть он, ищут имя узла, он идет (мои машины разработки имеют имена узлов, которые запускаются с "gabriel", таким образом, у меня просто есть это:

import socket
if socket.gethostname().startswith('gabriel'):
    LIVEHOST = False
else: 
    LIVEHOST = True

тогда в других первых частях имеют вещи как:

if LIVEHOST:
    DEBUG = False
    PREPEND_WWW = True
    MEDIA_URL = 'http://static1.grsites.com/'
else:
    DEBUG = True
    PREPEND_WWW = False
    MEDIA_URL = 'http://localhost:8000/static/'

и так далее. Немного менее читаемый, но это хорошо работает и сохраняет необходимость манипулировать несколькими файлами настроек.

В конце settings.py у меня есть следующее:

try:
    from settings_local import *
except ImportError:
    pass

Таким образом, если я хочу переопределить настройки по умолчанию, я должен просто поместить settings_local.py прямо рядом с settings.py.

У меня есть два файла. settings_base.py, который содержит общие / настройки по умолчанию, и который проверяется в управление исходным кодом. Каждое развертывание имеет отдельное settings.py, который выполняет from settings_base import * вначале и затем переопределяет по мере необходимости.

В дополнение к нескольким файлам настроек, упомянутым Jim, я также склонен помещать две настройки в свой settings.py файл в вершине BASE_DIR и BASE_URL набор к пути кода и URL на базу в сайте, все другие настройки изменяются для добавления себя к ним.

BASE_DIR = "/home/sean/myapp/", например, MEDIA_ROOT = "%smedia/" % BASEDIR

Поэтому при перемещении проекта я только должен изменить эти настройки и не искать целый файл.

я также рекомендовал бы смотреть на матрицу и Capistrano (инструмент Ruby, но это может использоваться для развертывания приложений Django), которые упрощают автоматизацию удаленного развертывания.

Я думаю, что это зависит от размера сайта относительно того, необходимо ли повыситься от использования SQLite, я успешно использовал SQLite на нескольких меньших живых сайтах, и это работает большой.

Мой файл settings.py находится во внешнем каталоге. Таким образом, он не будет возвращен в систему контроля версий или перезаписан при развертывании. Я поместил это в файл settings.py в моем проекте Django вместе с любыми настройками по умолчанию:

import sys
import os.path

def _load_settings(path):    
    print "Loading configuration from %s" % (path)
    if os.path.exists(path):
    settings = {}
    # execfile can't modify globals directly, so we will load them manually
    execfile(path, globals(), settings)
    for setting in settings:
        globals()[setting] = settings[setting]

_load_settings("/usr/local/conf/local_settings.py")

Примечание: это очень опасно, если вы не можете доверять local_settings.py.

Самый простой способ, который я нашел:

1) использовать settings.py по умолчанию для локальной разработки и 2) создать production-settings.py, начинающийся с:

import os
from settings import *

И затем просто переопределить настройки, которые отличаются в production:

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}