Question

我想在我的django进程启动时运行一些环境检查，并在发生错误时大声死亡。我认为数据库的编码不正确，或者机器有我们不支持的python版本。

我宁愿我们的团队面临他们必须解决的致命错误，而不是忽视它。

我写这些支票很好，但我很好奇放在哪里最合适的地方。如何让它们作为django启动过程的一部分执行？我以为可能有一个信号我也可以听，但我在文档中找不到相关的信号。

Answer 1

如果您不想使用设置模块，请尝试项目的__init__.py。

Answer 2

如果您想检查系统是否已正确安装，我认为您应该编写own admin command并将其作为安装后检查运行。

我认为不值得检查python版本是否经常正确安装，特别是如果您在共享主机上安装django应用程序。我的应用程序托管在alwaysdata，他们每小时重启一次FastCgi进程。这些检查会对应用程序响应时间产生影响。

Answer 3

我会把它们放在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

Answer 4

我们使用顶级urls.py。

Answer 5

我测试了所有三个__init__.py Settings.py和urls.py方法，这就是我找到的。

当代码从__init__.py或Settings.py运行时，启动功能在Web服务器启动时运行两次;当从urls.py运行启动函数时，代码运行一次，但它仅在第一次向我们的服务器发出请求时运行，导致第一个用户可能需要等待很长时间才能访问你的网站。

标准做法是在将大型Web应用程序重新联机时调用“预热”页面，因此我没有看到从urls.py中明确标识的位置调用启动函数应该是个问题。

Answer 6

你可以把它放在其他人提到的settings.py中，但在设置中使用代码并不理想。还可以选择为django.db.models.signals.class_prepared添加处理程序，该处理程序在准备好特定模型类之后执行所需的启动检查。

Answer 7

这里的大多数答案都非常古老，所以我认为这就是为什么没有提到Django's checks framework的原因。

自从至少v2（在撰写本文时，django == 3.1）开始，它就一直是django的一部分。

这可能是您需要的大多数支票的正确位置。

我仍会考虑使用settings，如其他答案所述，以检查需要settings内容的地方，但还需要在准备应用程序之前运行这些内容。

在django中放置额外启动代码的正确位置？

7 个答案: