Change Settings to raise ImproperlyConfigured on SECRET_KEY; not initialization

[Jon Dufresne]

Since ticket #17800, initializing settings without a SECRET_KEY raises a an ImproperlyConfigured during settings initialization.

Instead, I think the error should be raised when the setting is accessed as Settings.SECRET_KEY.

My use case, my project has a number of management commands that run in a non-production, minimally configured environment. These management commands do not require SECRET_KEY, however, the environment is forced to provide one.

As a workaround this environment has been generating a random secret key each run. If Django were to instead raise the error on SECRET_KEY access, this workaround would not be necessary.

[Jon Dufresne]

​PR

[Jon Dufresne]

Updated PR to address feedback. Thanks.

[Tim Graham <timograham@…>]

In b3cffde5:

Fixed #29324 -- Made Settings raise ImproperlyConfigured if SECRET_KEY is accessed and not set.

[Marten Kenbeek]

This causes a regression when using settings.configure(). UserSettingsHolder does not handle the missing SECRET_KEY attribute, and raises an AttributeError instead of ImproperlyConfigured.

(Discovered by bukensik in #django)

[Tim Graham]

​PR for the regression.

[Tim Graham <timograham@…>]

In 5cc81cd9:

Reverted "Fixed #29324 -- Made Settings raise ImproperlyConfigured if SECRET_KEY is accessed and not set."

This reverts commit b3cffde5559c4fa97625512d7ec41a674be26076 due to
a regression and performance concerns.

[Tim Graham <timograham@…>]

In 483f5d6c:

[2.1.x] Reverted "Fixed #29324 -- Made Settings raise ImproperlyConfigured if SECRET_KEY is accessed and not set."

This reverts commit b3cffde5559c4fa97625512d7ec41a674be26076 due to
a regression and performance concerns.

Backport of 5cc81cd9eb69f5f7a711412c02039b435c393135 from master

[Tim Graham]

I reverted the original patch for now as Claude expressed some concerns, "I'm not sure to like the additional test for every setting access, for a corner-case use case. I think we should consider reverting the initial patch instead."

I'll leave the ticket open for Jon to provide an alternative patch or to close the ticket as wontfix.

[Jon Dufresne]

​PR

[Jon Dufresne]

After researching the code necessary to handle the edge cases, I don't think the complexity is worth it to include in Django. I'll stick with my local project workaround instead.

[Florian Apolloner]

Reopening after recent ML discussion: ​https://groups.google.com/g/django-developers/c/CIPgeTetYpk

[Mariusz Felisiak]

​PR

[GitHub <noreply@…>]

In 948a8744:

Fixed #29324 -- Made SECRET_KEY validation lazy (on first access).