Django adoption could be improved
I have recently started developing with Django again and the experience has been quite rewarding so far except for some minor points which could be improved and would —I think— massively increase adoption.
Dreamhost
The first obstacle was to install a working Django on my shared Dreamhost server. I had developed some prototypes before using the Django development server but I had never gotten around to deploying anything on Apache because the process looked too complex. It turned out I was right to be intimidated.
There is a great guide for installing Django on Dreamhost by Jeff Croft and it looks like it should do everything I want, but after a bit I got quite stuck. Looking around and searching for a while made clear that Dreamhost requires a setting change for your hosting environment before it will run Python/FastCGI. After the support crew changed that setting, I fiddled a bit more and it worked.
This example does demonstrate why PHP is so dominant on the web. Any version of Apache with PHP installed will work out of the box. The only thing you have to do is to throw a .php file in a folder and point your browser to it. There are hardly any barriers to entry at work. I know PHP configuration and compatibility is quite difficult but in the general case it works out of the box for most users and that is what matters.
This is a given but installing Apache modules for every possible language by default is not a viable option forward. This article discusses some possible alternatives. I actually like the suggestion of using full blown HTTP servers in each application. I ran a Zope behind Apache with virtual host monster for years. Once you get it working it is really really solid or this was the part of my Zope installation which gave me the least amount of headaches.
Local development
Deploying a site on your webhost is a prerequisite but it is not the most ideal setup for development. It is doable —or would be if SSHFS did not run as slow on Dreamhost as it does— but I would rather have a local install. I had put setting this up off as well because it is also a difficult and annoying procedure. A quick rundown of the steps involved:
Downloading a Django release or a checking out from svn is pretty straightforward and that will run with the Python version that is installed on the Mac.
The problems start when you try to interface with a database. The two databases which you will probably use on the Mac are either sqlite which is already installed or MySQL which comes conveniently bundled in the MAMP package.
These databases run without problems but Python cannot talk to them. To interface with either database you need a third party module (e.g. pysqlite or mysql-python) which contains C code and needs to be built. You need to execute python setup.py build and for that to work you need a working gcc on your system. I sought around but I could not find readily compiled modules for a current OS X 10.4 for pysqlite.
I spent some time in #django asking for a way out of this fix and it seems that there are two ‘solutions’ to this problem neither of which is attractive.
- Find that ADC account that you lost track of long ago. Download the 1/2GB XCode from the Apple site which will take some time. Install this, build your Python module and then deinstall XCode again.
- Use either darwinports or fink and install the stuff you need along with all the dependencies. You can probably throw away the stuff when you’re done but I don’t know how and it might make your compiled library not work anymore, so all your effort may be wasted.
With both cases you have to download a massive package of developers’ tools to install a tiny library. In the case of the custom package managers the situation is even worse because the tools are massively complex and go completely against the grain of what a Mac is about. Users of fink and darwinport can do whatever they want, I just don’t want to be forced down the same path.
Everything on the Mac should be a single package which you can drop into /Applications and remove with similar ease. If MAMP and Locomotive can do it, why not everybody? There is an effort for Django but it is a bit premature.
It is doable of course but the size and complexity of the tools seem a bit disproportionate compared to the size of the library.
Another option I considered was asking a friend who has already installed Xcode to run the build step for me on the package and then recompress the folder and send it to me. Then I can install the already built files. As far as I can see, this procedure should work pretty fine on similar versions of OS X. The people in #django however discouraged me doing this for reasons of compatibility which were pretty vague. Isn’t there a decent way to distribute precompiled libraries on OS X?
Conclusion: I am an experienced Python programmer who really wants to like Django and I find these issues pretty tiring. Just think of how this must look to a web developer fresh over the fence from PHP, wanting to try something new. That process should be easier, because I am not that sure people like that will have the patience for these tribulations.
And now for a quick look at other stuff which I am not using.
Rails
Rails seems to have the getting started quickly thing down. But maybe Cristiano can tell us more about that.
Or not, I just found this guide to get started with Rail on the Mac. It is as long as my arm.
Rails is extremely popular right now. If I look at the job market, demand for Ruby is skyrocketing and I don’t know anybode in the Netherlands (save one) who whires Django developers. I still did not pick Rails because I am quite a proficient (5+ years) Python programmer and with a solid framework available for Python, it seems like a waste to throw all that experience away.
PHP
And to close off with a brief note about PHP, I watched a screencast for CakePHP today and it does the same thing for PHP what Django and Rails do.
But still in the screencast there is a lot of PHP ugliness which must be inherent when you are building a framework on that language. They also set a wrong example by allowing you to delete posts using a hyperlink which is a no-no.
So a nice option for if you are stuck with PHP but otherwise just come on over to the enlightened side of web programming.
So that was a long story. Any things I have missed or big failings in my reasoning? Feel free to point it out. I would like this process to be smoother, for me and for others.
Update: I see the Django wiki has a howto to setup development on Tiger which covers most of the same ground as I do but more pragmatically.

Reinier http://zwitserloot.com
May 15th, 2007Did they fix the issue where the db scaffolding is pointless yet?
I’m referring to the issue where you can actually stuff ‘illegal’ data into the database (e.g. UTF-8 woes), at which point the entire app stops working -including- the scaffolding, requiring you to dive into your db and manually fix the problem. That really tripped me up last time I had a look at django.
I’ve also had a look at turbogears, by the way, and the differences between the two are negligible. I’m a bit of a java afficionado so I feel I can say this with the proper gravity: Multiple Choices are Bad.
alper http://www.alper.nl
May 15th, 2007I don’t know about the scaffolding stuff. The only point where I ever broke Django’s admin interface is with outdated models, which are usually easy to fix.
It was probably a bug which has been fixed. Stuff like that tends to happen.
Multiple Choices? You mean the myriad of unusably heavy weight Java frameworks?
Reinier http://zwitserloot.com
May 15th, 2007>unusably heavy weight Java frameworks?
The very same. It’s the paradox of choice.