Flask + mod_wsgi automatic reload on source code change

Question

Does anyone know how to make a mod_wsgi automatically reload a Flask app when any of the modules changes? I\'ve tried WSGIScriptReloading On, but n

Answer 1

You're right about adding the WSGIScriptReloading directive. The Flask docs don't make it 100% clear, but Apache looks for changes to your .wsgi file. The recommended solution is to just execute a touch command on your your .wsgi file, as part of your release process.

Answer 2

What do you mean 'the official documentation is kind of a bear'? What is wrong with the included recipe:

• http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Monitoring_For_Code_Changes

That document also explains why WSGIScriptReloading doesn't do what you expect.

And no it is not possible to permanently crash on syntax errors. It is embedded in Apache and the whole point of Apache is to keep stuff running.

Sounds like you should not be using Apache/mod_wsgi for development. Everyones knows one should not use automatic source code reloading in production so can't imagine you would want to do that.

Answer 3

The correct answer to this question is that the WSGIScriptReloading On needs to be added into 000-default.conf present under /etc/apache2/sites-enabled folder.

See below example

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerName sentiments.live
        ServerAdmin admin@sentiments.live
        DocumentRoot /var/www/html
        WSGIDaemonProcess flaskapp threads=5
        WSGIScriptAlias / /var/www/html/sentiments/flaskapp.wsgi

        <Directory sentiments>
                WSGIScriptReloading On
                WSGIProcessGroup sentiments
                WSGIApplicationGroup %{GLOBAL}
                Order deny,allow
                Allow from all
        </Directory>

Answer 4

I think it's a very realistic situation to want to reload source code automatically in production. Think of an environment where sources are deployed per version and a 'production' symlink points to one of those versions. Whenever you want release a newer version, you just point the symlink to another path. But apache and mod_wsgi still collect the files from the symlinked directory and therefor need to have a reloading mechanism in place based on timestamps, size or w/e. Sure, one application might not be a problem, but what about hosting 15-20 applications that are all undergoing active development? Not automatically reloading sources is a pure loss in such a situation compared to restarting apache every single time.

Back to the question: if the framework you're using (in this case flask) does not have a plugin or tool in place for automatic source code reloading, then the two options described by Graham and Malphas are your best options. Either trigger the wsgi process to restart or implement a monitoring system.

Answer 5

For production I prefer apache mod_wsgi too, while for development I use the flask's built-in server. I separate prod and dev config files and I set the debug directive True in the dev config so that Flask can detect and reload code changes automatically.

Answer 6

With mod_wsgi, WSGIScriptReloading looks for changes to the .wsgi config file, rather than the code.

My workflow is to upload my code changes then just

$ touch MyWebApp.wsgi

which causes the last modified file timestamp to change and mod_wsgi to reload the code.

You can do this 'remotely' by saving the .wsgi file on your local machine and then uploading it again, or I just do it via SSH.

Not a lot you can do about syntax errors, the code is either running or it isn't, but a fix plus a touch will get it running again.

One gotcha to look out for if you're working via FTP: make sure you upload the 'touched' .wsgi file last otherwise it'll try and start with the wrong code.