Opened 9 years ago
Last modified 13 months ago
#27645 new Cleanup/optimization
Move Settings.__init__ checks to system checks
| Reported by: | Adam Johnson | Owned by: | |
|---|---|---|---|
| Component: | Core (Other) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | me@…, Ülgen Sarıkavak, Clifford Gama | Triage Stage: | Someday/Maybe |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Following #27626 there is some settings validation code in Settings.__init__ which predates the system checks framework and would be better moved to such checks.
Change History (7)
comment:1 by , 9 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|---|
| Version: | 1.10 → master |
comment:2 by , 9 years ago
comment:3 by , 5 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:4 by , 20 months ago
| Cc: | added |
|---|
comment:5 by , 20 months ago
948a874425e7d999950a8fa3b6598d9e34a4b861 moved the SECRET_KEY validation so Tim’s comment no longer applies there.
comment:6 by , 13 months ago
| Cc: | added |
|---|---|
| Owner: | set to |
| Status: | new → assigned |
comment:7 by , 13 months ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
| Triage Stage: | Accepted → Someday/Maybe |
The presence of an INSTALLED_APPS check in Settings.__init__() make this very difficult to solve:
When using management commands, settings are configured before system checks are run because ManagementUtility.execute() tries to configure the settings before executing commands; Commands are then responsible for running the checks they need to properly execute. This necessitates that the checks for this ticket should somehow run independently of other checks, before them, exiting if errors are found (otherwise other checks will crash if INSTALLED_APPS invalid).
An additional challenge in making that work is properly processing the errors as done in BaseCommand.check().
Supposing that were addressed, then additionally, accessing Django like this:
(djenv) clifford@anon:~/code/testing$ ipython Python 3.12.3 (main, Sep 11 2024, 14:17:37) [GCC 13.2.0] Type 'copyright', 'credits' or 'license' for more information IPython 8.27.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: import os, django In [2]: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "testing.settings") Out[2]: 'testing.settings' In [3]: from django.conf import settings In [4]: settings.INSTALLED_APPS Out[4]: "Not a list" # this bypasses system checks and will cause errors later
would also need to be handled, no? I'm not sure if this is a use case.
All of this adds complexity that seems disproportionate to the benefits.
In light of these issues, I am triaging this as "maybe/someday."
I noticed "Django will refuse to start if :setting:
SECRET_KEYis not set." indocs/ref/settings.txt." I'm unsure if the behavior should be kept, but system checks aren't executed when running Django throughwsgi.pyrather than throughrunserver.