I ran a slightly modified version of your test code since we have many
modules at "top level". "k3" is one of the top level modules that houses a
bunch of apps. In total there are about 1340 python files (including
recently squashed migrations and tests). Here's the results:
Project: 1575
I have done a lot more reading on this and I really feel pyinotify may not
be required, or we could at least switch to a watchman based service for
simplicity right away. Projects like uwsgi use a stat based approach, as do
most other projects I’ve seen and it appears to work ok for them. watchman
Thanks for the feedback! In the pull request I have re-added support for
pyinotify with tests, it was not as hard to write them as I believed. They
still fail, but I’m working on that!
I’ve found an interesting module confusingly called watchgod. The author
says[1] that with the new os.scandir()
While I understand the complexity of 1. I think shipping a version of
Django without
an equivalent inotify replacement such as watchdog could be problematic.
>From my personal experience when using Django's development server in Docker
containers sharing local volumes installing pyinotify
What do we think about removing the pyinotify functionality in the
autoreloader? For context, if pyinotify is installed (Linux only) the
autoreloader will attempt to use it to detect file changes over the
standard polling-based approach. It is generally much more efficient but is
not cross
