Конфигурация. dev vs production

У меня была другая мысль на эту тему: в массив или хэш заносим как настройки как для developer, так и для production. Затем на девелоперских (или на тестовых) машинах настраиваем переменную среды, равную некоему значению, по которому можно найти соотв. настройки в вышеописанном массиве. Затем при загрузке настроек просто извлекаем их их массива, пользуясь переменной среды как ключом. Игнорить ничего не надо, конфиг можно спокойно заливать с девелоперских и тестовых машин на сервер, на боевом сервере воротить ничего не надо (разумеется, следует предусмотреть вариант, когда переменная среды не установлена).

Мне нравится. Максимально простой и в тоже время рабочий способ.

Знаем и с удовольствием используем

И как же я, идиот, до этого не додумался ранее? :) Не джанговод, но и в пхп-проектах такой ход очень пригодится :)

как вариант можно и так,
но вообще для этой цели придумали make, ant, rake...

Я совсем не гордый, поэтому скажу — я такого не знал.
Элегантный подход. Спасибо и в избранное.

буду краток - спасибо! :)

Интересно за что карму минусят жёстко :-/

Не догадался как-то :) Да и удавалось обойтись без этого. Круто, спасибо.

Буквально вчера отказался участвовать в проекте, в котором в сеттингах было наворочено чего-то страшное - от выбора конфигурации в зависимости от имени машины и до кусков SQL каких-то. Остальное вроде выглядело поприличнее - тестами покрыто, не то чтобы страшно написано, но ощущение какое-то гнетущее производило :)

у меня всегда две ветки разработки: production и development. это совершенно разные «папки» и, соответственно, конфиги они используют разные.
непозволительно мне ковыряться в коде, которым пользуются пользователи.

что то сыкотно мне хранить реквизиты доступа к промышленным БД (и прочая) в разработческой ветке.

Мы организовываем настроечки чуть посложнее:
settings_base.py, целиком:
# Здесь описываем настройки, от которых зависят многие другие.
# В большинстве случае в новом экземпляре проекта
# достаточно подправить пути в этом файле.
sys.path.append('путь_до_библиотек_1')
sys.path.append('путь_до_библиотек_2')

PROJECT_ROOT = '/home/me/develop/project/'
MEDIA_ROOT = PROJECT_ROOT + 'media/'
SITE_URL = 'http://me:8000/'
ADMINS = (
('me', 'me@e-mail'),
)

Файл settings_base.py.sample, лежит в репозитории, settings_local.py игнорируется. Та же ситуация с settings_local.py.

часть settings.py:
from settings_base import *
# Здесь переопределяются настройки, зависимые от базовых.
# Далее часть grep-а по PROJECT_ROOT:
TEMPLATE_DIRS = (PROJECT_ROOT + 'templates/',)
LOCALE_PATHS = (PROJECT_ROOT + 'locale/',)
LOGGING_DIRECTORY = PROJECT_ROOT + 'log/'
APPLICATION1_COMMAND = 'java -parameters ' + PROJECT_ROOT + 'scripts/convertor.jar '
APPLICATION1_SETTINGS_FILE = PROJECT_ROOT + 'src/settings_format1.conf'
APPLICATION2_SCRIPTS_PATH = PROJECT_ROOT + 'module2_scripts_path/'
APPLICATION2_OBFUSCATE_COMMAND = 'java -parameters ' + PROJECT_ROOT + 'scripts/application2-obfuscator.jar %(source_file)s -o %(output_file)s'
APPLICATION3_TEMPLATES_ROOT = PROJECT_ROOT + 'templates/'
APPLICATION3_STYLES_ROOT = PROJECT_ROOT + 'styles/'
APPLICATION4_PARSER = PROJECT_ROOT + 'src/application4-parser/bla-bla-bla'
APPLICATION5_SERIALIZATION_DIRECTORY = PROJECT_ROOT + 'mymodule-data/'
# и ещё 4 сотни строк настроек разных приложений в том же духе, затем хвост:
from settings_local import *

часть settings_local.py:
# Здесь:
# 1) Переопределяются настройки, от которых, как правило,
# не зависят другие настройки.
# 2) Настраиваются специфичные обработчики - подключаются
# отладочные midlleware, добавляются консольные хандлеры для логгеров.
# Этот файл обычно небольшой.
import warnings
warnings.filterwarnings(action="error", category=DeprecationWarning)
warnings.filterwarnings(action="error", category=UserWarning)
DEBUG = True
TEMPLATE_DEBUG = True
APPLICATION6_USE_CACHE = False
SESSION_COOKIE_AGE = 14 * 24 * 3600 # 2 weeks
APPLICATION7_PERFORMANCE_LOG_INTERVAL = 3600
...