I actually spent the PyCon 2015 sprints working on a generic
watcher/reloader for Python servers, built on top of watchdog:
It should still be considered alpha/prototype code, but I think the
approach is promising. It uses a two-process model, where the master
process just monitors for file changes, and spawns a subprocess with the
actual server. The API is just a `run()` function that takes a dotted
import path to a serve-forever callable.
This model (as opposed to the single-process threads-only model used by
runserver) fixes the "killed by settings.py SyntaxError" problem,
because a failure in the server-running subprocess never kills the
master monitor process; the monitor just waits for the next file change
and tries again.
The question of which paths to monitor is orthogonal. Wsgiwatcher
currently follows the same "monitor everything in sys.modules" pattern
as runserver, but it could easily be modified to take a fixed directory
to watch instead. In fact that would simplify it quite a bit - currently
it has to use a multiprocessing Queue and a separate thread in the child
process to poll sys.modules and communicate the file list back to the
monitor process, and that could be removed.
The main potential issue with Wsgiwatcher's multi-process model (which I
haven't explored much yet) is how it interacts with multi-process
servers like gunicorn. This wouldn't be an issue for using it (or
something like it) with runserver.
I don't know that I'll have time to get back to Wsgiwatcher soon, but if
you (or Sam) are interested in working on alternative reloaders for
runserver, you're more than welcome to use it, improve it, and/or rip
off some code from it.
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com