You may have noticed that routes don’t work as you might expect them to in TurboGears 2.0. That is to say, that they don’t work the way the docs suggest they should.
If you just extend the TGController, it will try to do object dispatch routing, after your groovie routes have been applied.
If you just extend the DecoratedController, it will choke with an error like this:
In this article (the spiritual successor of the mod_wsgi article), I’m going to walk through the installation and configuration of a TurboGears 2.0 production environment, on top of Apache and mod_wsgi.
I assume you have Apache 2/mod_wsgi/virtualenv set up as we did in the previous post and an already functional TG2.0 app that works with the paster serve server.
I also assume that your python version is 2.4, but the same instructions should work for 2.3-2.5, just by replacing the string “python2.4″ with (e.g.) “python2.5″ wherever it appears below.
In this article, I’m going to walk through the installation and use of mod_wsgi for hosting Python web-apps.
Note: as of the posting of this article, mod_wsgi is up to version 2.5. The instructions should remain the same, just with the updated version number.
mod_wsgi is an Apache 2.0 module by Graham Dumpleton that provides a layer that WSGI enabled Python applications can talk to. Web frameworks like Pylons, TurboGears 2.0, and Django support the WSGI interface. It’s essentially an alternative to mod_python / CherryPy / Paster.
If you ever try to ./configure or make something on CentOS (or RHEL / Fedora) as a normal user, and it gives you sass:
$ make && make install unable to execute gcc: Permission denied error: Setup script exited with error: command 'gcc' failed with exit status 1
It’s probably because your user doesn’t have permission to run gcc. On CentOS4, only members of the compiler group (and root) can run gcc.
Solution? If this user needs to compile things, add them to the compiler group. It’s generally better to do this than to compile things as root, because, well, running foreign code as root is always risky.
To add a user to a group:
$ sudo /usr/sbin/usermod -a -G group_name user_name
or in this case, add the user to the compiler group:
$ sudo /usr/sbin/usermod -a -G compiler bob
Done!
If you haven’t used virtualenv before, it’s essentially a quick way of setting up customized Python environments. When one virtual environment is active, new packages are installed only to that environment, rather than your default Python site-packages directory, so you can easily avoid cluttering up your base Python installation with temporary, unstable, or otherwise unsavoury packages. In addition to this, you can set up a virtualenv with the --no-site-packages option. This will disable access to your default Python site-packages entirely. This makes it very easy to ensure the correct version of any particular package is in use. It is especially handy for development.
# to install virtualenv: $ sudo easy_install virtualenv # or, on macports: $ sudo port -v install py25-virtualenv
Using MacPorts, creating virtualenv environments with --no-site-packages enabled will fail when Python 2.5 applications try to access libraries like hashlib (including sha and md5).