Documentation: hypercorn and static files

[Sven R. Kunze]

Coming from the age-old problem of service static files, the usual process looks like this:

1) ✅develop and test using manage.py runserver and everything just works fine
2) ✅ deploy code using WSGI or ASGI as described in the docs
3) ❌ find out that static files are missing

Specifically referring to ​https://docs.djangoproject.com/en/3.1/howto/deployment/asgi/hypercorn/

As there is a dedicated documentation page for hypercorn, it doesn't look like there's a need for thinking of serving static files.

A friend of mine suggested to use whitenoise: ​https://github.com/evansd/whitenoise

Would it make sense to integrate this into the Django docs?

To be transparent here, I started also different threads on different channels but it seems like nobody really wants to tackle this issue, so I thought addressing the issue at least via Django sounds reasonable because it's a Web framework:
here: ​https://softwarerecs.stackexchange.com/questions/77600/simple-and-secure-command-line-http-server
and there: ​https://gitlab.com/pgjones/hypercorn/-/issues/173
from another guy: ​https://gitlab.com/pgjones/hypercorn/-/issues/45

As of now, I addressed my real-world setup by setting up a "mini"-nginx for now, serving static files and proxying hypercorn, but that does not feel like a holistic solution; also when it comes to automated deployment, permissions, principles such as "test as you fly, fly as you test" etc. it's a lot more brittle.

[Mariusz Felisiak]

Would it make sense to integrate this into the Django docs?

See #27325.

[Carlton Gibson]

Hi Sven. Not really sure what to say here.

I think it's a reasonable assumption that by the time you're deploying with ASGI you've already established your strategy for handling static files (or, at least, are intimately aware of the wiggles).

If you're just thinking about development, then we have #31626 to add support for ASGI to runserver. Until then, I think it's up to the individual servers (or users of those) to provide a static files solution. Channels provides a runserver implementation, including a static files middleware precisely for this.

Then, deploying behind nginx is the Standard Solution™ (if there is one) — you're are always meant to deploy Django behind a proxy, since protocol servers (Gunicorn, uWSGI, Daphne, uvicorn, etc) all expect that. (Why? Because they're deliberately not battle hardened to be exposed to the internet.)

Given that, having nginx serve your static files is the natural move. ("natural" and "holistic", whilst clearly not cognates, inhabit a close enough space I'd say. :)

This topic comes up on the DevelopersMailingList a couple of times a year I'd say. My summary would be that there are so many options and opinions on how to do it that we never reach anything close to a consensus for a new feature. contrib.staticfiles's collectstatic works well but what you do beyond that seems to be out of scope for Django itself.

Closing as a duplicate of #27325 — but TBH I'm not even sure there's really consensus for merging that. (There may be, with sufficient opt-outs...)

Hope that's sufficiently explanatory. It would be nice if it were simpler I do grant, but after all this time we're still lacking a proposal that folks agree on as an improvement…

[Mariusz Felisiak <felisiak.mariusz@…>]

In 8cd55021:

Fixed #32379 -- Started deprecation toward changing default USE_TZ to True.

Co-authored-by: Nick Pope <nick@…>
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@…>

[Mariusz Felisiak <felisiak.mariusz@…>]

In 602d9a3:

Refs #32379 -- Changed default USE_TZ to True.

Per deprecation timeline.