id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32534	Allow using StatReloader even if watchman is available	Evgeny Arshinov	nobody	"Hi,

Currently if Django discovers a compatible version of `watchman`, it unconditionally used WatchmanReloader instead of StatReloader. There is reason to do that because normally WatchmanReloader performs just as reliably as StatReloader while being more efficient. However, in my setup, which is WSL 2 + Docker with project dir mounted from Windows filesystem, watchman simply doesn't work because of non-functioning inotify. This lack of inotify support on WSL's part isn't clearly documented, but there are two issues WSL project members usually reference:
- https://github.com/microsoft/WSL/issues/4064
- https://github.com/microsoft/WSL/issues/4739

WSL people strongly recommend placing files to be mounted into Docker on the WSL filesystem (rather than Windows filesystem), but I have to keep them in Windows filesystem due to other issues in my development infrastructure. Not all of our development team members have to do that, so I can't exclude watchman from our development Docker image altogether which would ruin the autoreload experience for others.

What I suggest is an environment variable like `DJANGO_WATCHMAN_ENABLE(D)` / `DJANGO_WATCHMAN_DISABLE(D)` which would allow me to turn off watchman support without altering the Docker image.

References:
- Watchman support in django.utils.autoreload: https://code.djangoproject.com/ticket/27685
- [https://docs.djangoproject.com/en/3.1/ref/django-admin/#envvar-DJANGO_WATCHMAN_TIMEOUT DJANGO_WATCHMAN_TIMEOUT] - an existing watchman configuration option to be defined as an env var"	New feature	closed	Utilities	dev	Normal	wontfix	reload		Unreviewed	0	0	0	0	0	0