In short:
If you are using mod_wsgi, which we recommend, you will need to provide a WSGI script. All projects include a deploy/ directory which contains this script named pinax.wsgi. You may modify this file as it best suits you.
Here is a basic configuration for Apache (assuming you are using Python 2.5):
WSGIDaemonProcess mysite-production python-path=/path/to/virtualenvs/pinax-env/lib/python2.5/site-packages
WSGIProcessGroup mysite-production
WSGIScriptAlias / /path/to/project/deploy/pinax.wsgi
<Directory /path/to/project/deploy>
Order deny,allow
Allow from all
</Directory>
The above configuration will likely need to be modified before use. Most specifically make sure the python-path option points to the right Python version. We encourage you to read about WSGIDaemonProcess to learn more about what you can configure.
While we highly recommend you use mod_wsgi you may need to use mod_python. In this case we have provided the correct hooks for you to use Pinax. Here is a sample Apache config that you can use:
<Location "/">
SetHandler python-program
PythonHandler social_project.deploy.modpython
SetEnv DJANGO_SETTINGS_MODULE social_project.settings
PythonDebug On
PythonPath "['/path/to/pinax/projects'] + sys.path"
</Location>
Note
It is important to note that you should pay careful attention to the value of PythonHandler above. It is not using django.core.handlers.modpython. It is using a mod_python handler located in your project’s deploy/ directory. The reason why we have our own mod_python handler is because we need to setup the Pinax environment otherwise you will see failing imports.
Both mail messages and (some) notifications are queued for asynchronous delivery. To actually deliver them you need to run:
python manage.py send_mail
and:
python manage.py emit_notices
on a frequent, regular basis.
Because failed mail will be deferred, you need an additional, less frequent, run of:
python manage.py retry_deferred
We recommend setting up some scripts to run these commands within your virtual environment. You can use the following shell script as the basis for each management command:
#!/bin/sh
WORKON_HOME=/home/user/virtualenvs
PROJECT_ROOT=/path/to/project
# activate virtual environment
. $WORKON_HOME/pinax-env/bin/activate
cd $PROJECT_ROOT
python manage.py send_mail >> $PROJECT_ROOT/logs/cron_mail.log 2>&1
Let’s assume the scripts you create from above are stored in $PROJECT_ROOT/cron. You can now setup the cron job similar to:
* * * * * /path/to/project/cron/send_mail.sh
* * * * * /path/to/project/cron/emit_notices.sh
0,20,40 * * * * /path/to/project/cron/retry_deferred.sh
This runs send_mail and emit_notices every minute and retry_deferred every 20 minutes.
Pinax makes it very easy to combine all your applications’ media files into one single location (see Media Handling for details). Serving them more or less comes down again to how you do it with Django itself.
There is an example on how to serve those files with the development server in Serving static files during development.
In a production environment you, too, have to merge those files before you can serve them. Regarding actually serving those files then, see Django’s deployment documentation for details.