Hacker News Reader

Comment by VWWHFSfQ | Hacker News Reader

We just have a single settings.py and use django-environ to populate it.

    # settings.py

    from environ import Env

    ENV = Env()

    DEBUG = ENV.bool("DEBUG", True)
    SECRET_KEY = ENV.str("SECRET_KEY", "debug-secret-key")
    ALLOWED_HOSTS = ENV.list("ALLOWED_HOSTS", default=["*"])

    ...


    # Running with local .env
    $ foreman run -- python3 manage.py runserver

    # Running with prod.env
    $ foreman run -e prod.env -- python3 manage.py runserver

It's easy and scales well with a lot of settings/environments/developers.

View on HN

I realise that this is probably just an example for HN so this isn't criticism of your comment! But in case anyone reading doesn't know already, `runserver` is not appropriate for running in production.

It doesn't have any security hardening, is single threaded and blocking, will reload code as it changes, and is generally very slow.

It's generally best to use something like gunicorn, uwsgi, uvicorn, etc, and also to then host behind something like nginx which is designed to be exposed to potentially malicious users.

Furthermore I would like to add that having DEBUG set to True by default could lead you to accidentally enabling Django debug mode in production which could lead to accidentally leaking secrets.

We've gone back and forth on this a number of times internally and decided for the most part to just keep Django's defaults. There are a number of different ways that having "secure by default" can break your local development experience. For instance, if you accidentally run your local Django server with DEBUG=False, SECURE_SSL_REDIRECT=True, SESSION_COOKIE_SECURE=True, and any of the SECURE_HSTS_* settings your browser will basically remember that for all of eternity and you will no longer be able to just use http://localhost:8000/ without having to go figure out how to get it to "forget" all that stuff.

So for local development we follow the principle of least surprise, and we have a fairly rigorous policy/procedure for configuring and auditing production environment settings.

With a single settings file how do you handle things that should only ever be configured in a specific environment?

Django debug toolbar for example for a development environment? It needs to be listed as an installed app.

Or something specific to tests when the CI/CD pipeline is running the test suite.

The Django Debug Toolbar has a SHOW_TOOLBAR_CALLBACK setting that you can give a dotted import path to a function that returns True/False whether it should be enabled or not. By default it just looks at settings.DEBUG.

Other configurations work the same way.

Reply on news.ycombinator.com