Since I like simple/succinct guides, I thought I’d post what I did so others can follow in my stead.

Note: These instructions work with the python 2.5 version which ships with Leopard, or a self-compiled version of 2.6 (which is what I prefer) — see the InstallationOnMacOSX mod_wsgi page. Additionally, see the “Missing Code For Architecture” section for possible work-arounds if you find yourself needing 32 bit execution of Apache; I think the “Forcing 32 Bit Execution” are preferred over the “thinning” of the Apache binary.

First, download and install mod_wsgi on leopard, this is as easy as (on Leopard):

curl -o mod_wsgi.tgz http://modwsgi.googlecode.com/files/mod_wsgi-2.5.tar.gz
tar -xzf mod_wsgi.tgz
cd mod_wsgi-2.5
./configure
make
sudo make install

Now, edit (via sudo) /etc/apache2/httpd.conf and add the line:

LoadModule wsgi_module libexec/apache2/mod_wsgi.so

After the rest of the LoadModule lines. Cool.

Invariably all of my directions play with virtualenv/virtualenvwrapper and pip:

mkvirtualenv django
cdvirtualenv
easy_install pip
pip install http://media.djangoproject.com/releases/1.1/Django-1.1-rc-1.tar.gz
django-admin.py startproject mysite
django-admin.py startapp myapp
cd mysite
mkdir apache
mkdir media

Now, that just sets up the skeleton — the meat of the wsgi configuration goes in apache/ in the mysite/apache directory. The first file is named mysite.wsgi:

1
2
3
4
5
6
7
8
9
10
11

import os, sys
 
#Calculate the path based on the location of the WSGI script.
apache_configuration = os.path.dirname(__file__)
project = os.path.dirname(apache_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace)
 
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

This does the needed wsgi project magic for the Django application — don’t worry about the interpreter path; we’ll do that next.

Next up is a file named apache_django_wsgi.conf, this looks like this:

# mod_wsgi configuration directives - I like having stdout access, the other two
# options run mod_wsgi in daemon mode - more on this in a minute.
WSGIPythonHome /<path to virtualenv>
WSGIRestrictStdout Off
WSGIDaemonProcess django
WSGIProcessGroup django

#
# This should be the path of the /mysite/media directory
# for example "/Users/jesse/mysite/media/"
#
Alias /site_media/ "<PATH TO>/mysite/media/"
<Directory "<PATH TO>/mysite/media">
Order allow,deny
Options Indexes
Allow from all
IndexOptions FancyIndexing
</Directory>

#
# Directory path to the admin media, for example:
#

Alias /media/ "<PATH TO>/virtualenv/site-packages/django/contrib/admin/media/"
<Directory "<PATH TO>/virtualenv/site-packages/django/contrib/admin/media">
Order allow,deny
Options Indexes
Allow from all
IndexOptions FancyIndexing
</Directory>

#
# Path to the mysite.wsgi file, for example:
# "/Users/jesse/mysite/apache/mysite.wsgi"
#

WSGIScriptAlias / "<PATH TO>/mysite/apache/mysite.wsgi"

<Directory "<PATH TO>/mysite/apache">
Allow from all
</Directory>

The apache_django_wsgi.conf file is the meat-and-potatoes here. This sets up all the paths/permissions, and is in Apache httpd.conf format. You can pretty much logjam any apache configuration directive here that you like.

Your final step is to once again edit (via sudo) /etc/apache2/httpd.conf and add a line like this at the verrrrry bottom:

Include "/path to/mysite/apache/apache_django_wsgi.conf"

And then run “sudo apachectl restart”

You should now be able to hit http://127.0.0.1/ and see the friendly and inviting django welcome page. Note, that if you are using sqlite as your database, you should chmod a+rw the file, so that processes which are not you can mess with it.

There’s a final piece to this though. Normally, if you run mod_wsgi in embedded mode, you’re going to need to restart apache every single time you make a change to your django app.

Ah! But we’re running in daemon mode. This means all you need to do when you change a file is:

touch mysite/apache/mysite.wsgi

This will trigger a reload and magic happens. Me being as lazy as I am (ask my wife) ended up snagging Bruno Bord’s tdaemon script, and hacking it up a bit. The tdaemon script will watch a directory and run tests. Well, I wanted it to watch a directory (and let me filter sub directories) and then run that touch command. So I reused my watcher.py (here) — I used this to monitor my sphinx tree and run builds as well (and other stuff). Here’s how I’d use this:

workon django
cdvirtualenv
cd mysite
python ~/.slash/bin/watcher.py --command "touch apache/mysite.wsgi" -f media

This will auto-fire the touch command whenever it detects a file change (including svn updates).

You can also do this another way
In my rush to reuse a tool I use a bit (watcher) I skipped past the mod_wsgi document section on code reloading that shows how to setup a monitor which will watch .py file changes and kill the wsgi daemon, here. If you scroll down a bit, you’ll see the “Monitoring For Code Changes” section. All you need to do here is copy the code from the wiki into a module on your PYTHONPATH — in my case, I wrote it to mysite/apache/wsgi_monitor.py (just for this example! you should put it someplace else!) and then changed the mysite.wsgi file to import it, and set it up:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import os, sys
 
#Calculate the path based on the location of the WSGI script.
apache_configuration = os.path.dirname(__file__)
project = os.path.dirname(apache_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace)
 
sys.path.append(apache_configuration) # you probably shouldn't do this.
import wsgi_monitor
wsgi_monitor.start(interval=1.0)
 
os.environ['DJANGO_SETTINGS_MODULE'] = 'ui.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

This method — once you reload apache — will watch the project for changes and then kill the wsgi daemon (forces a reload). So there you go — two ways of doing it.

The nice thing about this setup is that I can make production version of the wsgi scripts and check them in, but keep local “my copies” (ala local_settings.py) additionally, I don’t have to jump through hoops to get static media and content served up via the django development server.

Additional reading:

• http://code.djangoproject.com/wiki/django_apache_and_mod_wsgi
• http://ericholscher.com/blog/2008/jul/8/setting-django-and-mod_wsgi/
• http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

So far, I’m loving it — but I’m also someone with about 500+ bookmarks in Safari, a ton of “to read” stuff saved on my hard drive, and over 100 RSS feeds in NetNewsWire. So something to help me archive/save/search everything is key.

Now I just want PDF indexing support.

Ok, I have 10 more left!

Quoting the sun rep:

“Now, the iPhone is open” as a target platform, Klein said. The free JVM would be made available via Apple’s AppStore marketplace for third-party applications.

Now, as comments there and elsewhere have pointed out — there’s a clause in the Agreement that comes with the SDK forbidding applications from being placed on the AppStore that can execute/interpret “other applications” — to whit:

3.3.2) An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and builtin interpreter(s).

So — unless Sun plans on making a JDK that a) doesn’t run anything or b) can be compiled into an application that is to be sold on the AppStore (providing the runtime for the app, like a self-standing .jar/.war) then I can’t see this happening, and option a is about as useful as a toilet bowl filled with taco meat.

On the other hand, option b: Making a runtime they release outside of the app store for application developers to use to write an application in Java and then have it compile-down to an Objective-C runtime/bytecode binary — then it could work, but those would be some *fat* binaries without a lot of magic.

Now — could the same thing be done with Python? Perhaps. Right now we have the pyObjC bridge that ships with Leopard that allows you mostly unfettered access into the Objective-C/OSX programming environment. This means you can build “native” applications in Python.

I doubt these bindings will work/exist on the iPhone, which means you want some utility to take Python code and “interpret” it down into an Objective-C binary, i.e.: an embed-able environment ala what Sun may end up having to do where you write an app in pyObjC/Python and the app+runtime is compiled down into Objective-C.

Again, without a lot of trickery, these would be fatass binaries — probably fatter than the notion of the universal binaries most people ship nowadays for OS/X.

It’s a thought — now I should get back to poking at Objective-C and other pre-pycon hackery. This is something people more versed in compilers, runtimes and with more free time than me will probably explore.

It’s call “BecomeAnXcoder” from CocoaLab

The cross-synchronization and the iPhone optimized version of the online client is what keeps me hooked (also the cold fact that without it, I’d have to prune my list of 117 feeds (including 6 planets and reddit/dzone)).

Yeah, it happened a few days ago, I’m still wading through a backlog of posts.

I particularly like his followup post on where he outlines how to use the new ‘run in python’ action to ship files off to Amazon’s S3 storage.

The latter of the two posts actually hooked me up with the “boto” python module — which looks like an excellent module for interacting with Amazon’s web services, something I’ve been examining recently for a side-project.

One of the cooler things that came out with Leopard was a completely overhauled PyObjC built-in. Including Webkit bindings, and many other things (see here and here for more details), a built-in version of twisted and many other things.

However, I was a moron. I was knee-deep in debugging a problem and compulsively replaced my came-with-leopard version of Python with the python.org python 2.5.1 build. (Anyone with tips on how to undo this, please let me know).

Once I dropped in the 2.5.1 version: poof. I managed to wipe out all of the delicious stuff built into my shiny new OS, which made me a sad panda. Once the PyObjC 2.0 stuff hit the PyObjC SVN tree (here) though, I was filled with hope that I could at least restore the PyObjC stuff.

Alas! It was not to be. Come to find out, there’s a hard coded string in the macpython makefile which causes the pyobjc build to use the wrong SDK and puke and die. After much wailing and gnashing of teeth, I gave up not realizing what the problem was. You should see a problem like this:

C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3

compile options: ‘-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 –c’
gcc: Modules/_Foundation_nscoder.m
Modules/_Foundation_nscoder.m: In function ‘imp_NSCoder_encodeArrayOfObjCType_count_at_’:
Modules/_Foundation_nscoder.m:220: error: ‘NSUInteger’ undeclared (first use in this function)
Modules/_Foundation_nscoder.m:220: error: (Each undeclared identifier is reported only once
Modules/_Foundation_nscoder.m:220: error: for each function it appears in.)
Modules/_Foundation_nscoder.m:220: error: syntax error before ‘count’
Modules/_Foundation_nscoder.m:228: error: syntax error before ‘i’
Modules/_Foundation_nscoder.m:249: error: ‘count’ undeclared (first use in this function)
Modules/_Foundation_nscoder.m:256: error: ‘i’ undeclared (first use in this function)


However, last night I was snowed-in at work and in between bug fixes for work, I managed to dig up a post (with fix) on the issue I was having (thanks Barry).

The short answer is sync the tree from subversion, and then edit the following file:

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/Makefile


And remove the “-isysroot /Developer/SDKs/MacOSX10.4u.sdk” chunk of text. Drop into the sync’ed svn tree and run the 02-develop-all.sh script. Now I can happily import WebKit:

Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import WebKit
>>>


And yes — it is as good as you’ve heard.

I’ll tell you this much — ever since I watched this screen cast by a guy using it for Python, I’ve spent a lot more time working on the more interesting language features.

I’ve added a lot of stuff pertinent to my work in the snippets, tab triggers, etc. I really have not been this happy with an editor in some time.

Really, you should check it out.

It’s interesting — it’s an SSH tunneling manager that sits in the Pref. Pane in OS/X instead of being a standalone application. For those of us who have to VPN a lot, but despise things like the official Cisco VPN client (on any damned platform) this might be useful (if you have ssh access into the corporate network).