Комментарии 44
У меня была другая мысль на эту тему: в массив или хэш заносим как настройки как для developer, так и для production. Затем на девелоперских (или на тестовых) машинах настраиваем переменную среды, равную некоему значению, по которому можно найти соотв. настройки в вышеописанном массиве. Затем при загрузке настроек просто извлекаем их их массива, пользуясь переменной среды как ключом. Игнорить ничего не надо, конфиг можно спокойно заливать с девелоперских и тестовых машин на сервер, на боевом сервере воротить ничего не надо (разумеется, следует предусмотреть вариант, когда переменная среды не установлена).
0
Не кажется, что это гемор?
+2
Раньше я делал примерно похоже на описанный marazm-ом способ, только "ровно наоборот".
Меня абсолютно не устраивал подход, при котором хоть локальный, хоть продакшновый файл с настройками не попадает в репозиторий, поэтому мне надо было сделать так, чтобы каждый из файлов был доступен, попадал в репозиторий, но на каждой из машин срабатывали только актуальные настройки. Поэтому я завёл файлы settings_common.py (содержащие всякие MIDDLEWARE_CLASSES, INSTALLED_APPS и т.п.), а также файлы settings-laptop.py, settings-webfaction.py, settings-dedicated.py, каждый из которых включал специфичные для машины вещи, но помимо этого, делал "from settings_common import *". И последним пунктом, на каждой машине я просто делал симлинк с settings.py на нужный из settings-*.py.
Потом мне надоела негибкость этого, и я сделал ровно по-твоему. SetEnv DJANGO_HOSTING_NAME "webfaction" или SetEnv DJANGO_HOSTING_NAME "laptop", и внутри единственного settings.py проверки на значение os.environ.get('DJANGO_HOSTING_NAME', None). Всё в одном месте, комфортно и удобно, и в SVN-е бэкапится.
Меня абсолютно не устраивал подход, при котором хоть локальный, хоть продакшновый файл с настройками не попадает в репозиторий, поэтому мне надо было сделать так, чтобы каждый из файлов был доступен, попадал в репозиторий, но на каждой из машин срабатывали только актуальные настройки. Поэтому я завёл файлы settings_common.py (содержащие всякие MIDDLEWARE_CLASSES, INSTALLED_APPS и т.п.), а также файлы settings-laptop.py, settings-webfaction.py, settings-dedicated.py, каждый из которых включал специфичные для машины вещи, но помимо этого, делал "from settings_common import *". И последним пунктом, на каждой машине я просто делал симлинк с settings.py на нужный из settings-*.py.
Потом мне надоела негибкость этого, и я сделал ровно по-твоему. SetEnv DJANGO_HOSTING_NAME "webfaction" или SetEnv DJANGO_HOSTING_NAME "laptop", и внутри единственного settings.py проверки на значение os.environ.get('DJANGO_HOSTING_NAME', None). Всё в одном месте, комфортно и удобно, и в SVN-е бэкапится.
0
М... Если количество девелоперов больше 1го - схема неудобная
0
НЛО прилетело и опубликовало эту надпись здесь
Мне нравится. Максимально простой и в тоже время рабочий способ.
0
Знаем и с удовольствием используем
0
И как же я, идиот, до этого не додумался ранее? :) Не джанговод, но и в пхп-проектах такой ход очень пригодится :)
0
как вариант можно и так,
но вообще для этой цели придумали make, ant, rake...
но вообще для этой цели придумали make, ant, rake...
0
Баян!:) Уже всё комьюнити этим сто лет как пользуется:)
-3
Прочитайте ещё раз вступление
+1
Ну баяном это быть не перестало, даже после вашего замечания. Лучше бы предложили новую концепцию какую-нибудь, чем мусолить уже давно известное.
-1
Вам ещё не показалось странным, что у вас 3 минуса за первый комментарий?
0
Ой, да? И что? Нет, вы правы вот уже 3 минуса точно говорят, что тема не баян, а вот было бы 2, то точно он. Еле уловимая граница прям.
-1
Как насчет констант?
-2
Symfony с самого начала создания проекта позволяет запускать/тестить его в dev и prod конфигурациях. Плюс можно свои конфигурации создовать.. Хм, не врут получается, когда пишут что взяли лучшее из других фреймворков. :)
-2
Я совсем не гордый, поэтому скажу — я такого не знал.
Элегантный подход. Спасибо и в избранное.
Элегантный подход. Спасибо и в избранное.
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
буду краток - спасибо! :)
0
Интересно за что карму минусят жёстко :-/
+1
Не догадался как-то :) Да и удавалось обойтись без этого. Круто, спасибо.
0
Буквально вчера отказался участвовать в проекте, в котором в сеттингах было наворочено чего-то страшное - от выбора конфигурации в зависимости от имени машины и до кусков SQL каких-то. Остальное вроде выглядело поприличнее - тестами покрыто, не то чтобы страшно написано, но ощущение какое-то гнетущее производило :)
0
у меня всегда две ветки разработки: production и development. это совершенно разные «папки» и, соответственно, конфиги они используют разные.
непозволительно мне ковыряться в коде, которым пользуются пользователи.
непозволительно мне ковыряться в коде, которым пользуются пользователи.
0
что то сыкотно мне хранить реквизиты доступа к промышленным БД (и прочая) в разработческой ветке.
0
Мы организовываем настроечки чуть посложнее:
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
...
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
...
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конфигурация. dev vs production