I do have a use-case where having a default SECRET_KEY makes things much
easier - docker.
Normally you can't run management commands in a Dockerfile if there's no
secret key (and often other things) set, and usually it's best to run
collectstatic as a build step.
So your options end up being:
Hello,
On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
Florian Apolloner wrote:
> On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com
> wrote:
>
> > Personally, I think that *at minimum* providing Django-builtin "get
> > from env" helpers would be great; beyond that, I'd love to have
>
Hi,
On 6/26/20 12:11 PM, René Fleschenberg wrote:
> geared towards development (random default value for SECRET_KEY, DEBUG =
> False).
I meant DEBUG = True here, of course :)
--
René Fleschenberg
--
You received this message because you are subscribed to the Google Groups
"Django developers
Hi Flo,
> And there are plenty more things to consider; for instance I do not
> agree that it makes sense to have "SECRET_KEY" default to a value when
> missing in the env. It is way to easy to type "SECRT_KEY" and never
> realize that. So if "SECRET_KEY" is taken from the environment it should
>
>
> i dont belive in adding default names to environment variables, they're up
> to the user to define
>
Javier, I think you missed what Florian was talking about. He was
suggesting there shouldn't be default *values* for some settings.
> I personally rather have no solution in Django itself
Hi Florian, thank for your input, i dont belive in adding default names to
environment variables, they're up to the user to define. Nothing will be
given by default, you need the SECRET_KEY? `from_env` has no idea what that
means, its just another name, so you tell it what it will do with this
Hi there,
On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com wrote:
> Personally, I think that *at minimum* providing Django-builtin "get from
> env" helpers would be great; beyond that, I'd love to have them be
> included around `DEBUG` and `SECRET_KEY` with the current values
Hi Carsten, great question! The idea as i see it is: having the least
amount of moving parts the better. The trick here is unification, keep a
single settings file with 99% of the configuration needed using environment
variables/secrets/zookeeper/etc to swap out environment specific options
Hello,
Am 25.06.20 um 19:51 schrieb Kit La Touche:
> […] Once we see how this gets used, we can see about passing it a file
> instead of `os.environ`, […]
This is probably a stupid question, but what is the advantage of this (and env
vars) over this:
In project_dir/project_dir:
settings.py
