After a long hiatus, as far as doing any serious work on mod_wsgi, I have finally been getting up the motivation to work on mod_wsgi again. I have been doing some refactoring of code in the core of mod_wsgi, but I have mainly been playing with stuff that sits around mod_wsgi which makes it easier to install and run, especially for local development and testing. This is all as a prelude to some grander ideas I have for down the track.
At this time I have thrown up an early beta version of this new experiment to get some feedback on it and to shake out any problems with it. if you have the time to try it out and give me any comments you have, that would be most excellent. The express version of the instructions you need to try out this repackaged version of mod_wsgi are as follows: 1. Install it. pip install wsgi_module 2. Run it on your WSGI script file. wsgi-admin serve path/to/app.wsgi And that is all there is to it. You will now have Apache running on port 8000 with mod_wsgi hosting your WSGI application. Summarising some things in case you missed it. This is making mod_wsgi available as a Python package on PyPi which can be installed using pip. The resultant mod_wsgi.so and associated files get installed into the Python installation or virtual environment and not into your existing Apache installation. This means you do not need to have root access. What the 'wsgi-admin serve' command will do is create an Apache configuration file on the fly based on any options which are supplied, but otherwise it uses a configuration for Apache/mod_wsgi which I deem is a good configuration for running mod_wsgi with Apache. This means you don't have to understand how to configure Apache, I have done that part for you. In effect what you have at this point is the equivalent of a standalone Python WSGI server. It will run in the foreground and will not daemonise. If you really wanted it to be daemonised, then run it under supervisord. You will also need to use supervisord at the moment if you wanted it to run as a certain user if starting it automatically when your system boots. The 'wsgi-admin' script 'serve' command has a small set of options to allow you to do the most common things that are required when using Apache/mod_wsgi. The script will work out all the appropriate Apache/mod_wsgi configuration and do it in the appropriate way to ensure it all works fine. To get the available options run: wsgi-admin serve -h At the moment this yields. Usage: wsgi-admin serve script [options] Options: -h, --help show this help message and exit --host IP-ADDRESS --port NUMBER --processes NUMBER --threads NUMBER --callable-object NAME --reload-on-changes --document-root DIRECTORY-PATH --url-alias URL-PATH FILE-PATH|DIRECTORY-PATH --keep-alive-timeout SECONDS --server-status --include-configuration FILE-PATH --working-directory DIRECTORY-PATH --server-root DIRECTORY-PATH --log-directory DIRECTORY-PATH --httpd-executable FILE-PATH --modules-directory DIRECTORY-PATH --mime-types FILE-PATH --with-newrelic --with-wdb So documentation of the options is obviously one of the things still to be done, so a quick run down of a few usage scenarios. 1. Specifying the host. By default the Apache instance will listen on localhost only. This means it will not be accessible outside of the host it is running on. To make it accessible through any interface use: wsgi-admin serve app.wsgi --host 0.0.0.0 2. Changing number of processes and threads. Daemon mode is always used. It will default to a single process with 5 threads. To change the number of processes and thread use: wsgi-admin serve app.wsgi --processes 3 --threads 10 In addition to setting these for the daemon process group, the script will automatically calculate some values for the number of Apache child worker processes and threads which are proxying to the daemon process group running the WSGI application. This works irrespective of whether your Apache installation happens to be using prefork, worker or event MPM. 3. Development mode. As is usually the case with daemon mode, you can touch the WSGI script file and your application will be reloaded on the next request. If however you are doing development and would rather that code be automatically reloaded as you make changes to it, you can use: wsgi-admin serve app.wsgi --reload-on-changes That way there is no need to touch the WSGI script file or restart Apache manually. As with any such automatic reloading mechanism, it is only for development and you should not use it in production. 4. Hosting of static files at the root of the site. By default it only hosts your WSGI application. If however you have static files you also need to host and they need to be available from the root of the site, such as favicon.ico, then use: wsgi-admin serve app.wsgi --document-root path/to/files What will happen is that your WSGI application is still mounted at the root URL, but if when a request is received it matches a file in the document root directory, that file will be served up instead. In other words, if a file is found it is served. If a file can't be found, the request is passed to the WSGI application. 5. Hosting of static files at a sub URL of the site. It is not always the case that files are organised into a nice directory structure which would allow you to mount that directory at the root of the site using --document-root. In this case you can mount a directory at a sub URL instead. For example, if using Django, where static files are put together into one directory using the 'collectstatic' management command, but where the directory structure created by 'collectstatic' doesn't include a sub directory corresponding to the sub URL it needs to appear as on the web server, you can use: wsgi-admin serve mysite/wsgi.py --url-alias /static mysite/files You can use the --url-alias option more than once. The script will ensure that they are all ordered correctly to give the correct precedence if there are overlaps. 6. Want to do some performance monitoring. There is inbuilt support for New Relic. So long as you have also installed the Python 'newrelic' package and have signed up for New Relic (it has a free Lite tier), you can run: NEW_RELIC_CONFIG_FILE=newrelic.ini wsgi-admin serve app.wsgi --with-newrelic 7. Need help debugging errors from your application. There are various debuggers which allow debugging in the browser. A more recent one which has some advantages over others is wdb (https://github.com/Kozea/wdb). So long as you have the 'wdb' package installed you can use: wsgi-admin serve app.wsgi --with-wdb There is no need to run the separate 'wdb.server.py' command as the Apache configuration will be setup to automatically run it from the web server in a separate isolated mod_wsgi daemon group process. This way it is always started up and shutdown automatically for you without caring. If using Django, just note the need to set; DEBUG_PROPAGATE_EXCEPTIONS = True in your Django settings file so that exceptions are propagated back up to the WSGI server. 8. Change the directories where things are placed. By default a directory is created in '/tmp' to put the files which are generated to do all this. The directory is of the form: /tmp/apache-host:port:hid The log file is called 'error_log' in that directory. You can override that directory name using '--server-root'. You can separate override the directory used for the log file using '--log-directory'. So, what are the requirements for using this. In order to install it you must have Apache 2.2 or 2.4 installed on your system. On a Linux system, you need to have both the core Apache packages, as well as the corresponding 'dev' packages. For example, if using Ubuntu and you have: - apache2 - apache2-mpm-worker you also need: - apache2-threaded-dev If you have: - apache2 - apache2-mpm-prefork you also need: - apache2-prefork-dev You will need to work out what you need to install for your system, but if you have previously compiled mod_wsgi from source code, you will already have what you need. If you are on MacOS X Mountain Lion, you may need to fix up a bug in the Apple Apache/Xcode package caused by a wrong path in the Apache 'apxs' configuration. This is fixed by doing: cd /Applications/Xcode.app/Contents/Developer/Toolchains sudo ln -s XcodeDefault.xctoolchain OSX10.8.xctoolchain This will be trashed by some system updates and will need to be added back if that occurs. When pip is run, the setup.py will go looking for the Apache 'apxs' program in your PATH or '/usr/sbin'. If it isn't in your PATH or you want to use a different Apache installation, use: APXS=/some/other/path/bin/apxs pip install wsgi_module That should be more than enough to get you started if you are interested. Try it out for doing development, see how it goes and let me know. Overall I think I am already pretty close to where I want this, but will still be doing some internal code cleanups at least. If you have got any other ideas, or the way the Apache configuration is done will not let your application run, then let me know. Time to go to sleep and see what anyone comes up with tomorrow. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
