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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29324>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/9876 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:1>
* needs_better_patch: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:2>
* needs_better_patch: 1 => 0
Comment:
Updated PR to address feedback. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:3>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"b3cffde5559c4fa97625512d7ec41a674be26076" b3cffde5]:
{{{
#!CommitTicketReference repository=""
revision="b3cffde5559c4fa97625512d7ec41a674be26076"
Fixed #29324 -- Made Settings raise ImproperlyConfigured if SECRET_KEY is
accessed and not set.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:4>
* status: closed => new
* resolution: fixed =>
* severity: Normal => Release blocker
Comment:
This causes a regression when using `settings.configure()`.
`UserSettingsHolder` does not handle the missing `SECRET_KEY` attribute,
and raises an `AttributeError` instead of `ImproperlyConfigured`.
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:5>
* has_patch: 1 => 0
* version: master => 2.1
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:6>
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/9974 PR] for the regression.
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:7>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"5cc81cd9eb69f5f7a711412c02039b435c393135" 5cc81cd9]:
{{{
#!CommitTicketReference repository=""
revision="5cc81cd9eb69f5f7a711412c02039b435c393135"
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.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:8>
Comment (by Tim Graham <timograham@…>):
In [changeset:"483f5d6c4f66c8dfca5770de7b1af8aea05a5e7c" 483f5d6c]:
{{{
#!CommitTicketReference repository=""
revision="483f5d6c4f66c8dfca5770de7b1af8aea05a5e7c"
[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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:9>
* status: closed => new
* has_patch: 1 => 0
* resolution: fixed =>
* severity: Release blocker => Normal
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:10>
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/10512 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:11>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:12>
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:13>
* status: closed => new
* resolution: wontfix =>
Comment:
Reopening after recent ML discussion: https://groups.google.com/g/django-
developers/c/CIPgeTetYpk
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:14>
* owner: nobody => Florian Apolloner
* needs_better_patch: 1 => 0
* status: new => assigned
Comment:
[https://github.com/django/django/pull/13240 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:15>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:16>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"948a874425e7d999950a8fa3b6598d9e34a4b861" 948a8744]:
{{{
#!CommitTicketReference repository=""
revision="948a874425e7d999950a8fa3b6598d9e34a4b861"
Fixed #29324 -- Made SECRET_KEY validation lazy (on first access).
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29324#comment:17>