The reloading mechanism is implemented by forking worker processes from a
parent monitor. Start by defining an entry point for your process. This must
be an importable path in string format. For example,
myapp.scripts.serve.main:

# myapp/scripts/serve.pyimportsysimporthupperimportwaitressdefwsgi_app(environ,start_response):start_response('200 OK',[('Content-Type','text/plain'])yield[b'hello']defmain(args=sys.argv[1:]):if'--reload'inargs:# start_reloader will only return in a monitored subprocessreloader=hupper.start_reloader('myapp.scripts.serve.main')# monitor an extra filereloader.watch_files(['foo.ini'])waitress.serve(wsgi_app)

Many applications will tend to re-use the same startup code for both the
monitor and the worker. As a convenience to support this use case, the
hupper.start_reloader() function can be invoked both from the parent
process as well as the worker. When called initially from the parent process,
it will fork a new worker, then start the monitor and never return. When
called from the worker process it will return a proxy object that can be used
to communicate back to the monitor.

By default, hupper will auto-select the best file monitor based on what
is available. The preferred order is watchdog then polling. If
watchdog is installed but you do not want to use it for any reason, you
may override the default by specifying the monitor you wish to use instead in
the HUPPER_DEFAULT_MONITOR environment variable. For example: