I'd love to see better support for PaaS configuration, especially 12-factor. We
use Heroku, and I've been directly exposed to the challenges and had to come up
with some of my own solutions. Here's some thoughts I have on the matter, in no
particular order.
The SECRET_KEY needs to _not_ be required for the `collectstatic` command. I
haven't tracked down why it currently _is_ required, but it means that I have
added this line to my project, solely so that my project can be built on Heroku.
SECRET_KEY = os.environ.get('SECRET_KEY', 'not-so-secret')
SECRET_KEY is effectively optional (though I'm careful to make sure it's set),
and I don't see a good reason that should be. Note that environment variables
aren't normally available during slug build, since changing environment
variables doesn't re-build the project.
I believe that the biggest current impediment to finding a great solution to
loading Django settings is that the settings are based on a Module.
Django-Configurations has done an excellent job of making that into a
class-based API instead, which allows for mixins and inheritance. Having
built-in support for this would be an excellent way to allow 3rd party
solutions to build up settings programatically. In the case we are discussing,
from the environment.
I believe this would make it far easier for projects like Kristian's
django-12factor and dj-email-url to work well. dj-email-url is a good idea (put
all the settings in 1 variable, like dj-database-url), except that all the
settings are split up at the top-level of the module, making what's
conceptually one multi-facted setting a multi-line pain.
One possibility would be extending `DJANGO_SETTINGS_MODULE` with an optional
class, separated with a colon, so to get a django-configurations style class
you'd use `DJANGO_SETTINGS_MODULE=myproject.settings:MySettings`. Or we could
change the variable name `DJANGO_SETTINGS`, which would allow us to avoid the
colon: `DJANGO_SETTINGS=myproject.settings.MySettings`. Or paint the bikeshed
some other color.
I'd love to see some of the support for environment configurations brought into
Django, but IMO moving away from a module based settings API is a more pressing
concern that would enable 3rd party libraries to come up with elegant solutions.
> On Apr 11, 2016, at 4:32 AM, Kristian Glass
> <googleto...@doismellburning.co.uk> wrote:
>
> I wrote django12factor to do something similar. One of the things I like
> least about it is the process of actually using it from your settings.py -
> there's things in there I'd love to see in the generated default.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2D66F14E-DD71-41B6-A84D-A0C679FD72F5%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.
