Move Settings.__init__ checks to system checks

[Adam Johnson]

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.

[Tim Graham]

I noticed "Django will refuse to start if :setting:SECRET_KEY is not set." in docs/ref/settings.txt." I'm unsure if the behavior should be kept, but system checks aren't executed when running Django through wsgi.py rather than through runserver.

[Adam Johnson]

948a874425e7d999950a8fa3b6598d9e34a4b861 moved the SECRET_KEY validation so Tim’s comment no longer applies there.

[Clifford Gama]

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 because INSTALLED_APPS invalid). An additional challenge here being 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 resolving this as "maybe/someday."