Closed amirreza8002 closed 6 months ago
I don't think that's quite right. The docs note that you can enable WhiteNoise "also" for local development, which is what we've done here. By adding -nostatic
it automatically handles state file handling locally (and in production).
Let me know if I'm missing something here!
hi
so what i understand from the doc is that in development that django's own server is used with the runserver
command, django takes over the static file handling.
this is supported by the document that states: you can either add --nostatic when running runserver or add this line to installed apps
but in production that command is not used, and we typically use a dedicated server such as gunicorn or the like
while it doesn't hurt to leave that line in there, i think making it explicit that this is for development is a good thing so people know the tool they are using better
I think the key here is that runserver
acts as BOTH a local server and serves files. In production, you have to swap both of these out: gunicorn
is a popular option as a WSGI server and whitenoise
for production file serving.
The Whitenoise docs state, "For this reason it’s a good idea to use WhiteNoise in development as well." If we installed Whitenoise but did not add it to INSTALLED_APPS, then we would have to do python manage.py runserver --nostatic
manually each time. By adding it to INSTALLED_APPS, we can just use runserver
and Whitenoise takes over.
I appreciate your PR and the discussion. If you disagree, feel free to fork the project and implement how you prefer.
https://whitenoise.readthedocs.io/en/latest/django.html#using-whitenoise-in-development
according to this doc this setting is only used for development