Deploying [http://trac.edgewall.org Trac] to my [http://hostgo.com shared hosting provider's] servers was not the easiest experience in the world. So what, you ask, was so hard about it... well let me tell you. === 1. No SQLite (or Python SQL binding of any kind) === So this was probably the hardest part to deal with. My hosting provider has not only a very old copy of Python installed on their servers... they don't have any SQL modules installed. So what do you do when if you're in an environment like this? Give up? Hell no! You go and find a pure Python MySQL binding! [https://github.com/petehunt/PyMySQL/ PyMySQL] PyMySQL required some modifications to be made to the Trac mysql_backend. I was deploying Trac 0.12.3 and I've attached a patch to this post in case anyone else feels the need to try this in the future. The PyMySQL binding was missing an implementation of the Connection.store_result method. So I just tweaked it to not care (it was using it while trying to determine the character encoding set on the DB... which might be an issue... but so far has been okay). This also broke something else (initialization of another method) so I tweaked that as well to handle the problem. === 2. CGI only === Sadly this makes Trac a little bit slow... but I can live with it. Getting it setup was kind of a pain though. The trick here turned out to be reusing my hosting provider's existing cgi-bin. I'm actually writing this before I've deployed the whole system live (for testing) but the fact that this makes the URL kind of ugly is being hidden using mod_rewrite. '''Update:''' I thought it might be useful to show the mod_rewrite rule I'm using in my .htaccess file. {{{ RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /cgi-bin/trac.cgi/$1 [L,QSA] RewriteRule ^$ cgi-bin/trac.cgi [L] }}} '''Update2:''' This also needed to be added to the top of the trac.cgi to get the URLs within Trac to point to the rewritten URL locations instead of the original cgi-bin ones. The solution to this was found in this [http://trac.edgewall.org/ticket/7500 Trac bug report]. {{{ import os if 'SCRIPT_URL' not in os.environ and 'REDIRECT_URL' in os.environ: os.environ['SCRIPT_URL'] = os.environ['REDIRECT_URL'] }}} === 3. Gotta use virtualenv === I guess there's nothing really "wrong" with this. But I generally haven't had to use it for my Trac installations. This might actually be a good thing for the future if I never need to setup dozens of Trac instances on a server. It allows you to keep all of them nicely separated. I followed [http://ches.nausicaamedia.com/articles/technogeekery/pimping-your- trac-and-python-on-textdrive-part-i this tutorial] while setting up this portion. But other than that the install was just a typical Trac install. Easy as always. Easy to install some plug-ins ([http://trac- hacks.org/wiki/FullBlogPlugin FullBlog], [http://trac- hacks.org/wiki/AccountManagerPlugin AccountManager]). A little bit of hassle with getting authentication configured. But those are all pretty normal problems you'd encounter with any Trac install. '''Update 3''' === 4. You can't live without some sort of spam filter === After the blog was up for just a few days with anonymous comments enabled... it got flooded with a bunch of spam. :-( I set up the [http://trac.edgewall.org/wiki/SpamFilter TracSpamFilter] and configured it to use [http://www.google.com/recaptcha reCaptcha]. Once I figured out the completely dumb misconfiguration I had (the Admin module was completely disabled so I couldn't configure it) it was pretty easy to set up. I think the only interesting thing about my configuration is that I've set a minimum karma so that the captcha will be shown for all anonymous users the first time they try to post a comment. There might be a bug with comment previews... but I'm still tracking that down.