Frankly, it’s not easy. At all (actually this is why I think MySQL is so popular, because of the ease of installation!) So hang tight and read on.

Installation

Russ Brooks says it is better to avoid MacPorts: I must say that indeed, I tried installing PostgreSQL with MacPorts and I got seriously stuck, unable to do anything with it, not even starting the server. So I uninstalled the PostgreSQL MacPorts package and found other options: a PostgreSQL for Mac installer, and Marc Liyanage’s own installer. I decided to go with the first one, since Marc’s installs version 8.1 of the server, and PostgreSQL for Mac offers version 8.3.

The installation goes without trouble, using a standard installer (which means that you need administrative privileges, as usual). However, you want to read these explanations before doing anything ;)

NOTE: if you have trouble installing PostgreSQL using the above installer (as I did after the unsuccessful MacPorts installation / desinstallation), open Terminal.app and try these commands:

$ sudo dscl localhost >cd Local/Default/Users/ >ls

If you see a “postgres” entry in the list of local users, delete it and re-run the installer:

>delete postgres

After the Installation

The installer puts the PostgreSQL installation into /Library/PostgreSQL8. You should add the path to the PostgreSQL binaries in your PATH environment variable before doing anything else:

export PATH=/Library/PostgreSQL8/bin:$PATH (bash) setenv PATH /Library/PostgreSQL8/bin:$PATH (tcsh)

Then, type the following commands to create the default database, owned by the “postgres” user:

cd /Library/PostgreSQL8/ sudo rm -r data sudo mkdir data sudo chown postgres:postgres data cd bin sudo -u postgres initdb -E utf8 /Library/PostgreSQL8/data

In my case (Leopard-powered PowerBook G4) I had the “Shared Memory error” that Russ talks about. So I followed his advice: I created a file named /etc/sysctl.conf with the following contents, then rebooted my computer and everything went fine:

kern.sysv.shmmax=4194304 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1024

I also used dscl to change the password of the postgres user (otherwise, how to know which is it??)

>passwd postgres postgres

The installer adds some handy utilities on your /Application folder (see the image above). You can also use pgAdmin to manage the database server. Very handy. I tried to use phpPgAdmin but without success (can’t get past the login screen… :(

And that’s it! There are interesting resources out there explaining how to use it from Rails or Django, so I’ll start reviewing them…

[source:python] import unittest

loader = unittest.TestLoader() tests = loader.loadTestsFromName(‘path.to.your.tests.package’) for test in tests.tests: print test._tests[0].class.name.replace(“Test”, “”) for method in test._tests: print ” %s” % method._testMethodName.replace(“test“, “”).capitalize().replace(“_”, ” “) [/source]

This would yield something like this: Business     Accounts have at least one entry     Clerks cannot close accounts Security     Users can create new accounts     Anonymous users cannot access private areas ...

Of course, you’ll get better results if you follow Google’s naming conventions for your tests… ;) This is not rspec (nor an alternative to it) but it might be useful to some of you.

Just as a reminder for Django users: you might need to

setenv DJANGO_SETTINGS_MODULE application.settings

or

export DJANGO_SETTINGS_MODULE=application.settings

in order to make the script work properly! At least I had to :)

As you might know (and if you don’t I’ll tell you anyway), Django’s views (somehow occupying the “Controller” level in an MVC architecture) must take (at least) an HttpRequest instance as a parameter and must return an HttpResponse instance. That’s how it goes in Django, this is the law. This means that you must be sure that the last instruction in your request processing code (in whichever way you’ve organized it) must return an HttpResponse instance, usually calling the HttpResponse() constructor (or of any of its useful subclasses), or by calling the django.shortcuts.render_to_response() function, or something similar.

This has, in my opinion, a major drawback: it might limit code reuse and it increases the coupling in the code. Everything’s not lost, however.

Before you start the flame wars, let me explain, using an example coming from the Django website; this represents a basic Django view function, returning some response containing data fetched from the database:

[source:python] from django.shortcuts import render_to_response, get_object_or_404

…

def detail(request, poll_id): p = get_object_or_404(Poll, pk=poll_id) return render_to_response(‘polls/detail.html’, {‘poll’: p}) [/source]

Let’s say now that I want to reuse that particular data (the ‘p’ variable) in another view: given that the return value is always an HttpResponse instance, you are screwed; sometimes you just need the data, to find something, or simply to render it in another format like JSON or XML (RESTful architectures, anyone?). This goes pretty much against the DRY principles, and if you don’t go deeper than the Django tutorials, your whole application might feature lots of repeated code.

Even worse, you have a direct reference to a template (“polls/detail.html”), and this kind of coupling does not scale well. It can become a real problem in big projects.

There are, however, strategies to avoid this: the first, the most common, is to refactor your code and to create a “layer” of data-specific functions, which will return instances (or arrays thereof) that you can reuse here and there. Doing this in a big project already started requires a good deal of unit testing first, to ensure that your refactoring is not breaking something elsewhere, but that’s another problem (because you DO unit test, right??). This approach might not scale well in complex projects, and thus you would like to organize your code in other ways.

I learnt about organizing views using callable objects instead of functions while studying the code in the Django REST Interface project. In this case, you create code like this:

[source:python] class Resource(ResourceBase): “”" Generic resource class that can be used for resources that are not based on Django models. “”"

# ... snip ...
def __call__(self, request, *args, **kwargs):
    """
    Redirects to one of the CRUD methods depending
    on the HTTP method of the request. Checks whether
    the requested method is allowed for this resource.
    """
    # Check permission
    if not self.authentication.is_authenticated(request):
        response = HttpResponse(_('Authorization Required'), mimetype=self.mimetype)
        challenge_headers = self.authentication.challenge_headers()
        response._headers.update(challenge_headers)
        response.status_code = 401
        return response
    try:
        return self.dispatch(request, self, *args, **kwargs)
    except HttpMethodNotAllowed:
        response = HttpResponseNotAllowed(self.permitted_methods)
        response.mimetype = self.mimetype
        return response

[/source]

The important bit here is the “call” method, which allows an instance to be called as a function, without specifying any particular method. This makes me remember of the dreadful VB default methods but in Python it’s not that bad, actually (VB is horrible by default anyway), and allows you to use a cool syntax to do complex tricks (“command pattern” way of doing things, without the method call overload). And of course, since you are using an object-oriented approach, you can use polymorphism and inheritance to organize and reuse code as much as you can (or want).

Finally, Marco told me that his team uses another cool approach: they avoid returning HttpResponse instances from the views, and instead use Python decorators to generate those. This way, you can achieve another neat separation of concerns, and you can reuse code simply and effectively.

I understand that the Python philosophy cares about explicitness, but the “easy” way of processing requests in Django leads to trouble in big applications: increased coupling, reduced DRY, more headaches. I think you should use some code-reuse strategy in your Django code, but this, of course, is more an architectural problem than a Django problem.

[source:python] from cStringIO import StringIO from django.test.client import Client as DjangoClient, encode_multipart from django.utils.http import urlencode import base64 import md5

class Client(DjangoClient): “”" Wrapper and drop-in replacement around Django’s own test “Client” class, providing PUT, DELETE and OPTIONS support, as well as HTTP Basic + Digest Authentication support. NOTE: the django.test.client.Client does not directly support PUT, DELETE or OPTIONS requests so we’re using the “request()” method directly… there’s an open ticket about it: http://code.djangoproject.com/ticket/5888 “”"

auth = { }
def http_basic_login(self, username, password):
    base64string = base64.encodestring('%s:%s' % (username, password))[:-1]
    self.auth = { "HTTP_AUTHORIZATION": "Basic %s" % base64string }
def http_digest_login(self, method, url, params, response, username, password):
    (authmeth, auth) = response['WWW-Authenticate'].split(" ", 1)
    if authmeth.lower() != 'digest':
        return
    amap = {}
    for itm in auth.split(", "):
        (k, v) = [s.strip() for s in itm.split("=", 1)]
        amap[k] = v.replace('"', '')
    try:
        realm    = amap['realm']
        qop      = amap.get('qop', '')
        nonce    = amap['nonce']
        opaque   = amap['opaque']
    except:
        return
    cnonce = "01b6730aae57c007"
    nc = "00000001"
    query_string = "&".join(["=".join(item) for item in zip(params.keys(), params.values())])
    uri = url + "?" + query_string
    ha1 = md5.md5('%s:%s:%s' % (username, realm, password)).hexdigest()
    ha2 = md5.md5('%s:%s' % (method, uri)).hexdigest()
    if qop:
        chk = "%s:%s:%s:%s:%s:%s" % (ha1, nonce, nc, cnonce, qop, ha2)
    else:
        chk = "%s:%s:%s" % (ha1, nonce, ha2)
    response = md5.md5(chk).hexdigest()
    self.auth = {
        "HTTP_AUTHORIZATION": 'Digest username="%s", realm="%s", nonce="%s", uri="%s", response="%s", opaque="%s", qop=auth, nc=%s, cnonce="%s"' % (username, realm, nonce, uri, response, opaque, nc, cnonce),
    }
def http_logout(self):
    self.auth = {}
def pre_request(self, url, data):
    r = {
        'CONTENT_LENGTH':  None,
        'CONTENT_TYPE':    'text/html; charset=utf-8',
        "HTTP_USER_AGENT": "Django Unit Test HTTP Client",
        'PATH_INFO':       url,
        'QUERY_STRING':    urlencode(data, doseq=True),
    }
    r.update(self.auth)
    return r
def get(self, url, data, **extra):
    r = {}
    r.update(extra)
    r.update(self.auth)
    return DjangoClient.get(self, url, data, **r)
def post(self, url, data, **extra):
    r = {}
    r.update(extra)
    r.update(self.auth)
    return DjangoClient.post(self, url, data, **r)
def delete(self, url, data):
    r = self.pre_request(url, data)
    r["REQUEST_METHOD"] = "DELETE"
    return self.request(**r)
def options(self, url, data):
    r = self.pre_request(url, data)
    r["REQUEST_METHOD"] = "OPTIONS"
    return self.request(**r)
def put(self, url, data, form):
    BOUNDARY = 'BoUnDaRyStRiNg'
    MULTIPART_CONTENT = 'multipart/form-data; boundary=%s' % BOUNDARY
    encoded = encode_multipart(BOUNDARY, form)
    r = self.pre_request(url, data)
    r.update({
        'CONTENT_LENGTH': len(encoded),
        'CONTENT_TYPE':   MULTIPART_CONTENT,
        'REQUEST_METHOD': 'PUT',
        'wsgi.input':     StringIO(encoded),
    })
    return self.request(**r)
def hello(self, url, data, **extra):
    """Sends a fake 'HELLO' request which returns a 405 answer :)"""
    r = self.pre_request(url, data)
    r["REQUEST_METHOD"] = "HELLO"
    r.update(extra)
    return self.request(**r)

[/source]

Hope it helps! Of course you could extend this to support OPTIONS, HEAD or other HTTP methods you could find in the specification.

Update, 2008-03-05: Following Yoan’s comment below, I’ve DRYed the code a bit. Neat.

Update, 2008-03-11: I’ve added HTTP Basic Authentication support to the class (and changed the post title accordingly).

Update, 2008-03-13: Another modification: now the client supports HTTP Digest Authentication (Yay! To use it, make a first call to your server and then pass the response as a parameter to the http_digest_login method), plus support for the OPTIONS verb, plus another method which sends a method with a “HELLO” verb, which of course does not exist… and which will (normally) return a 405 response!

OK, I’m actually building the API myself this time. That’s why so few posts this month. RESTful, featuring multiple export formats, secure, configurable, usable on top of any existing Django application. It can even generate its own wrappers in a myriad of programming languages.

The problem is, basically, that if you try to do the “easy_install MySQL_python” thing, it won’t work in Leopard (the compilation of the native code fails). Here’s how I made it work, following the instructions in this post in the MySQL forums, and doing some tweaking manually.

1. Download MySQL_python source code from SourceForge
2. Download MySQL’s source code for Mac OS X in tarball form (watch out, there’s code for Universal binaries, and for platform-specific ones – PowerPC or Intel!)
3. Unpack both files; this will generate two folders, one mysql-5.0.45-osx10.4-powerpc (I’m on a G4 Mac, your folder might end with “intel”) and MySQL-python-1.2.2
4. In the MySQL-python-1.2.2 folder, edit the _mysql.c file; comment out lines 37 to 39: [source:c:firstline(34)] #else #include “my_config.h” #endif //#ifndef uint //#define uint unsigned int //#endif #include “mysql.h” #include “mysqld_error.h” #include “errmsg.h” [/source]
5. If you use MAMP, you should add to your PATH the location of the “include” and “lib” directories (to allow proper compilation and linking of the extension, as you might have imagined); in tcsh you would do something like this: setenv PATH /Users/adrian/Downloads/mysql-5.0.45-osx10.4-powerpc/include:/Users/adrian/Downloads/mysql-5.0.45-osx10.4-powerpc/lib:$PATH (of course, replace “adrian” with your own user name ;)
6. Now build and install MySQL_python as you would normally do: python setup.py build sudo python setup.py install
7. If you have MySQL installed in /usr/local/mysql, then the MySQL_python code should work right now. If it doesn’t (because you use MAMP), you should copy the contents of the mysql-5.0.45-osx10.4-powerpc/lib folder into “/usr/local/mysql/lib/mysql/” (pay attention to the fact that there is “mysql” twice in that path name). This is needed because the code is compiled in such a way that it loads the MySQL library dynamically, and the code is configured to do so.

After this, I could change the configuration of the Django blog code to use the MAMP MySQL database:

[source:python:firstline(15)] DATABASE_ENGINE = ‘mysql’ DATABASE_NAME = ‘blog’ DATABASE_USER = ‘root’ DATABASE_PASSWORD = ‘root’ DATABASE_HOST = ‘/Applications/MAMP/tmp/mysql/mysql.sock’ DATABASE_PORT = ’8889′ [/source]

Pay attention to the fact that Django is prepared to use the MySQL socket instead of the hostname, when the DATABASE_HOST variable starts with a slash (“/”).

Now, create an empty “blog” database using phpMyAdmin, and a simple python manage.py syncdb will create an empty schema for you to use in the application.

Phew! Hope this helps! :)

Creating this project I have had a practical experience comparing both Django and, of course, Rails. The subject is not new in this blog; however, this time I could play with both frameworks and as such, I can bring my small amount of confusion in this big framework tar pit. Personally, I found Django and Rails much more different than I previously thought. Both frameworks tackle similar problems, sometimes in similar ways; however; but this does not make for a real similarity between both. They have different philosophical approaches to the problem. This must surely have to do with the underlying programming language and their philosophies.

That said, I found Rails much easier to use. It took me far, far less time to do a similar small application in Rails than it took me to do it on Django. And I must say that when I first used Rails, I had never seen a line of Ruby in my life. I will list some pros and cons that I found in the process:

Good things about Django:

• The “automatic administration system”; impressive! (but you can get it in Rails with some external plugins like Streamlined… but in any case it’s a handy thing to have it already in the system!)
• The form subsystem; great!
• Django does not force you a folder layout; nice!
• The Django Book + documentation: really great resources, nothing to say about that.
• The deployment procedure: really much easier than Rails! We’re in something really close to PHP here, while Capistrano has much more to do with Java’s Maven or even makefiles :)
• The native support for RSS feeds! This is a godsend.

Bad things about Django:

• No native support for “environments”, like in Rails; you cannot separate easily the settings for development, testing and production (and you can add more environments if you want!)
• No native support for REST architectures, or at least “easy” AJAX + API support (like the one you find in Rails)
• The “syncdb” system that ships with Django is, at most, primitive, compared to Rails migrations.
• There doesn’t seem to be a built-in infrastructure for tests. There is a primitive built-in test infrastructure. You can add “doctests” to your views and models, and this way you’re “documenting and testing” at the same time. Sorry, but I don’t buy this. Tests are tests, docs are docs. Rails, thanks to rakefiles and unit, functional and integration tests, seems is a much more advanced platform in this sense. You can get even stats of your projects with it! You can test them! Extract the docs! Everything! This is something lacking in Django. Really. Not to speak about the lack in Python of something similar to RSpec, which just by itself justifies the choice of Ruby and Rails in this field.
• Lack of integrated logging. Can you believe this? I had to find an external source of inspiration for this.
• The naming of “Views” for “Controllers” (or said otherwise, the MTV instead of MVC thing) does not make sense to me. Even in WebObjects and Cocoa “views” are, well, “views”…
• The commands for creating, starting or using an application from the command line are slightly harder to remember (or maybe in Rails are just far too easy to remember!)
• The template system; I do not want to learn another language for that. Django uses a really limited one for this matter, and I prefer Rails’ (default) one in this case.
• Finally, Python; I just can’t get used to this language’s syntax. But I can live with that ;) It’s a matter of personal taste, simply.

Of course, these impressions have nothing to do with the power of the platform! Python is a powerful language, and many of the “newbie” observations above have to do with my own lack of knowledge about it. But first impressions count!

In any case, I liked playing with Django & Python; I’m happy to have learnt something new!

Update, 2009-02-26: I’ve posted the code in Github now, and also I’ve fixed its compatibility problems, and now it works with Django 1.0.2.

In any case, I had to install a working Django environment in my machine, and while following the excellent and free Django Book instructions, this is what I did in my Leopard installation to have it up and running (Leopard already comes bundled with Subversion 1.4.4, Python 2.5.1 and SQLite 3.4.0, so you don’t need to do anything about them):

1. Checkout the latest version of Django from its Subversion repository:
   cd ~ svn co http://code.djangoproject.com/svn/django/trunk django_trunk This will create a ~/django_trunk folder in your home directory.
2. Edit the .tcshrc file (yes, I use tcsh) with the following instructions: setenv PATH /Users/adrian/django_trunk/django/bin:$PATH setenv PYTHONPATH /Users/adrian/django_trunk This will make the Django files available to your Python installation.
3. Open Terminal.app and cd to your ~/Desktop
4. Follow my instructions about how to fix the bug in Leopard’s Terminal.app, which can be quite disappointing after all.
5. Create a new Django project: django-admin.py startproject [PROJECT_NAME]
6. Start the development server: python manage.py runserver [IP:PORT] [PORT] By default it listens on the port 8000, so you can browse to http://localhost:8000/ to see your fresh new system.
7. Start the command-line interface (similar to Rails’ “script/console”): python manage.py shell
8. If you follow the Django Book instructions, you might find that you cannot use models with “ImageField” columns; you need to install first the Python Imaging Library doing the following: curl http://effbot.org/media/downloads/Imaging-1.1.6.tar.gz -o Imaging-1.1.6.tar.gz tar xvfz Imaging-1.1.6.tar.gz cd Imaging-1.1.6 python setup.py build sudo python setup.py install cd .. rm Imaging-1.1.6.tar.gz rm -r Imaging-1.1.6
9. That’s all!

I hope this helps. Doing these steps I could have a working installation, and everything shown in the book worked perfectly well. It’s an impressive framework! I look forward to learn more about it.

Hope this helps!

PS: yes, I’m doing Django and hence Python these days ;)

For those interested, Django is a powerful, MVC framework for creating web applications using the Python programming language. It is very similar in some respects to Rails, but some consider Django to be better suited for high-traffic websites. I haven’t used Django extensively (nor Python as a matter of fact, besides the typical “Hello World” thingy) so I won’t say anything else but the fact that I prefer Ruby‘s syntax to Python’s.

Of course this is a subjective opinion! In any case, if it’s anything like Rails, it’s worth considering. Definitely. Dynamic languages are the way to go.

Update, 2008-01-11: You might want to check out this other article of mine!