Корректное место для помещения дополнительного кода запуска в django?
Отвечать на Ваш дополнительный вопрос:
Этот вопрос ускорил мой запрос. tea.h файл не делает ссылки на tea.c файл. Компилятор "Знает", что каждый.h файл имеет соответствующий.c файл?
компилятор, прежде всего, не касается заголовочных файлов. Каждый вызов компилятора компилирует источник (.c) файл в объект (.o) файл. Негласно (т.е. в make файл или файл проекта) командная строка, эквивалентная этому, сгенерирована:
compiler --options tea.c
исходный файл #include с все заголовочные файлы для ресурсов, на которые это ссылается, который является, как компилятор находит заголовочные файлы.
(я заминаю некоторые детали здесь. Существует много для приобретения знаний о создании C проектов.)
5 ответов
Я бы поместил их в settings.py. Раньше я проводил проверки системы следующим образом:
try:
from local_settings import *
except ImportError:
print "Missing %s" % os.path.join(PROJECT_ROOT, "local_settings.py")
if DEBUG:
for p in [PROJECT_ROOT, MEDIA_ROOT, THEME_DIR, ADMIN_MEDIA_ROOT] + list(TEMPLATE_DIRS):
p = os.path.normpath(p)
if not os.path.exists(p):
print "Missing path: %s" % p
Если вы не хотите использовать модуль настроек, попробуйте проект __ init __. Py .
Если вы хотите проверить правильность установки системы, я думаю, вам следует написать свою собственную команду администратора и запустить ее в качестве проверки после установки.
Я думаю, что не стоит слишком часто проверять, правильно ли установлена версия python, особенно если вы устанавливаете приложение django на shared-host. Мое приложение размещено на alwaysdata, и они перезапускают процесс FastCgi каждый час. Эти проверки могут повлиять на время отклика приложения.
Вы можете поместить его в settings.py, как упоминалось другими, но наличие кода в настройках - не лучший вариант. Также существует возможность добавления обработчика для django.db.models.signals.class_prepared, который выполняет требуемые проверки запуска после подготовки определенного класса модели.