django.utils.autoreload.get_child_arguments() detected when Python was
started with the `-m` option only for `django` module. This commit
changes the logic to check __spec__, see
https://docs.python.org/3/reference/import.html#main-spec
Now packages can implement their own __main__ with the runserver
command.
This reverts commit e286711879 which
caused permission errors when users didn't have permissions to all
intermediate directories in a Django installation path.
Thanks Jakub Szafrański for the report.
With an error in the loop above (e.g. using query without args), this
would trigger a busy loop. While this was caused due to changes to the
loop itself, it seems to be just good practice to protect against this.
Previously we updated the file mtimes if the file has not been seen
before - i.e on the first iteration of the loop.
If the mtime has been changed we triggered the notify_file_changed()
method which in all cases except the translations will result in the
process being terminated. To be strictly correct we need to update the
mtime for either branch of the conditional.
Regression in 6754bffa2b.
With this change, it's expected to survive anything except errors
that make it impossible to import the settings. It's too complex
to fallback to a sensible behavior with a broken settings module.
Harcoding things about runserver in ManagementUtility.execute is
atrocious but it's the only way out of the chicken'n'egg problem:
the current implementation of the autoreloader primarily watches
imported Python modules -- and then a few other things that were
bolted on top of this design -- but we want it to kick in even if
the project contains import-time errors and django.setup() fails.
At some point we should throw away this code and replace it by an
off-the-shelf autoreloader that watches the working directory and
re-runs `django-admin runserver` whenever something changes.
* When some old files contain errors, the second call to
gen_filenames() should return them.
* When some new files contain errors, the first call to
gen_filenames(only_new=True) should return them.
Commit 15f82c7 ("used pyinotify as change detection system when
available") introduced a regression where editing a file in vim with
default settings (writebackup=auto) no longer causes the dev server
to be restarted. On a write, vim moves the monitored file to a backup
path and then creates a new file in the original. The new file is not
monitored as it has a different inode. Fixed this by also watching for
inotify events IN_DELETE_SELF and IN_MOVE_SELF.