Allow for runserver development server warning to be silenced via settings.

[Klaas van Schelven]

Since Django 5.2 Django emits this warning.

WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.

For more information on production servers see: ​https://docs.djangoproject.com/en/5.2/howto/deployment/

I _know_ this and act like it. To avoid warning fatigue, I keep the number of displayed warnings as close to 0 as possible. Doing so is annoying for the current warning (it can be done via the env, but not using a setting).

I would like to have a first-class tool to get this thing to shut up :-)

Discussed ​here and ​here (with similar reasonings)

[Natalia Bidart]

Hello Klaas van Schelven! Thanks for the suggestion and for taking the time to create this ticket. In general, adding new settings to Django requires strong community consensus and clear justification. In this case, the existing environment variable offers a reasonable workaround, and it's not much different from defining a setting. We don't currently see a need to introduce a dedicated setting for this, therefore I'll close the ticket accordingly.

[Klaas van Schelven]

Hmmm... there seems to be some tension between

the existing environment variable .. is not much different from defining a setting

and

adding new settings to Django requires strong community consensus and clear justification.

also: I wonder how many of Django's behaviors are configurable via os envs _only_ (I know of no other examples myself).

which to me suggests that it's the behavior that was implemented in 5.2 that needed the _clear justification_.

oh well...this is probably not the hill that I'll die on

[Natalia Bidart]

Replying to Klaas van Schelven:

also: I wonder how many of Django's behaviors are configurable via os envs _only_ (I know of no other examples myself).

which to me suggests that it's the behavior that was implemented in 5.2 that needed the _clear justification_.

Fair points, and thanks for the thoughtful reply.

My view is that Django settings are best reserved for configuration values that affect the behavior of the web service itself (i.e. when running in "real" deployments) not development-time conveniences. For those, environment variables strike a better balance without expanding the settings surface. It's somewhat like hiding warnings (which can be done via an env var), but quite different from silencing system checks (which is actually a setting) which are often tied to actual deployment readiness and can impact whether a real server should run at all.

oh well...this is probably not the hill that I'll die on

I appreciate you raising it, and I agree it's not a hill to die on.

[Klaas van Schelven]

Thanks for your thoughtful reply.

My view is that Django settings are best reserved for configuration values that affect the behavior of the web service itself

I get that!