Доброго времени суток ;)
Вот волею судеб(яндекса с гуглом ;) ) Натнулся на джангу и стал осваивать …. Пока больше плюсов нарыл чем минусов … Но вот вопросик собственно как лучше разнести настройки сайта\базы для ветки разработки и стабильного хвоста ?

мне ничего умнее решения в лоб - перекурочить settings.py
с соответственно рабочие настройки жестоко в него (settings.py) забиты , а если надо чего-нибуть попробывать клонируем проект и кладем в app_config.py настройки для тестовой базы …. Если велосипед - наставте на путь истинный плиз…. А то просто как-то не сложилась сразу идеология разработки в команде для джанги …

У вас получилось некое гибридное решение между монолитным файлом и разделением на общую и частную часть.

Идеологически конечно лучше избавиться от try except и продакшен настройки тоже хранить отдельным файлом.

Вообще ситуация классическая. Есть несколько сред в которые нужно выкатывать проект. Это разработка, тестирование и продакшен. Последние две среды обычно строго детерминированы и их настройки для удобства можно хранить в системе контроля версий, например в отдельной директории.

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

Чтобы локальные настройки не смешивались, я бы предложил в тестинге и продакшен файл app_config делать символьными ссылками на соответствующий файл в репозитории. Девелоперы же пусть прям в корень проекта кладут свои локальные настройки и вольно их меняют по необходимости.

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

ну тогда уж симлинк на settings.py под текущий вариант … но очередные грабли - у меня товарсч пасеться на ХРюше … и нехотит слезать(ну его право) а мам …. ну как-то кисло с линками ….
делать _копию_ файла imho не кошерно - зачем болото разводить … вот и решили с дополнительным конфигом повыпендриваться…

Maddy
ну тогда уж симлинк на settings.py под текущий вариант ..

Нет, это уже другое - суть глобальных и локальных настроек теряется.

Maddy
но очередные грабли - у меня товарсч пасеться на ХРюше … и нехотит слезать(ну его право) а мам …. ну как-то кисло с линками ….

Не понял вас. Наверно на другой язык перешли:-)

Daevaorn
Maddy написал:

но очередные грабли - у меня товарсч пасеться на ХРюше … и нехотит слезать(ну его право) а мам …. ну как-то кисло с линками ….

Не понял вас. Наверно на другой язык перешли:-)

Наверное ;) Я сам предпочитаю Дебиан для разработки … А напарник на WinXP (хрюшка;) ) и она (ХР) только хард-линки понимает вроде ….
Вообще была идея сделать профили запуска и не мучиться …. но пока недошли до такого ;)

lorien
Я просто делаю *в конце* settings.py

О блин ! зачот ;) спасибо за снятие с ручника ;)

Maddy
А напарник на WinXP (хрюшкаwink ) и она (ХР) только хард-линки понимает вроде ….

В любом случае всегда можн явным образом указать файл настроек. Который вовсе не обязательно должен лежать в директории проекта и называться settings.py

Junction - симлинки для Win (на NTFS)
Сам иногда использую.

lorien
Я просто делаю *в конце* settings.py

я тоже так сделал примерно:
Код:
try:
from local_settings.myproject1.bd_settings import *
except ImportError:
pass


причем settings_local у меня cимволная ссылка на каталог который лежит вне директории проекта

подумал что символическую ссылку можно убрать а вместо этого добавить путь в PYTHONPATH знаю как это сделать в win xp, но в линуксе(ubuntu) недавно, подскажите где это можно прописать чтобы питон искал модули еще в моей директории local_settings?