jessenoller.com - So you want to use python on the mac?

I've been doing a fair bit of of Mac development and have come to appreciate the syntax of Objective-C. One of the more interesting aspects of Cappuccino is that it has created a new dialect of JavaScript that they call Objective-J. This blog post explains some of the motivations they had for doing this. In any event, I decided that I'd like to give Cappuccino a spin.

My "go to" language for server back ends is Python. I also like CherryPy, a Python server framework that makes it easy to attach Python code to web requests. Since Cappuccino is designed to make it easy to build an application inside a browser window, the back end mostly needs to be able to serve up JSON data for the Cappuccino application to present. CherryPy makes this fairly easy.

To get started, I downloaded the the Cappuccino "Starter Package". Inside that zip file is a "NewApplication" directory. I copied that directory as a directory called "static" in the my Application directory. If you open the supplied index.html, you are presented with a very basic "Hello World" application written in Cappuccino. In order to to build the application I have in mind though, I want that index.html to come from my CherryPy server so that the Cappuccino application can easily request information.

To do this, I configured my CherryPy application to server the contents of my Application/static directory. This is readily accomplished by creating a CherryPy configuration file cherrycappuccino.ini:

 
[global]
tools.staticdir.root = "/Users/keith/Projects/CherryCappuccino/Application"
 
[/]
tools.staticdir.on = True
tools.staticdir.dir = "static"
 

This tells CherryPy to server the contents of my "static" directory statically.

What remains is the Python code that builds the CherryPy application. At this point it's quite simple. We create one object that's mounted on the root of the CherryPy server. It's index method simply returns the contents of the index.html file in the static directory (there might be other ways to accomplish this but this was expedient. Here's the Python code from cherrycappuccino.py in my Application directory:

 
import cherrypy
 
class CherryCappuccino:
    def __init__(self):
        self.indexText = None
 
    @cherrypy.expose
    def index(self):
        if not self.indexText:
            indexFileName = os.path.join(os.path.dirname(__file__),"static","index.html")
            indexFile = open(indexFileName)
            self.indexText = indexFile.read()
 
        return self.indexText
 
cherrypy.quickstart(CherryCappuccino(),'/',"cherrycappuccino.ini")
 

This reads the cherrycappuccino.ini file to configure the application and starts the server with our single application object. Starting the server with "python cherrycappuccino.py" sets up the server that can be browsed to at http://localhost:8080.

In a future post, I'll show how to configure the Cappuccino view based on data returned from the server.

Which is to say that while my eyes will still glaze over during a discussion of the relative merits of different delta storage mechanisms, I know enough to know why the latest crop of distributed version control (DVCS) systems are interesting and that I wanted to use one of the "big three" (Git, Mercurial, Bazaar).

I didn't bother trying Git. Mostly because cross platform support (especially Windows support) didn't seem to be "job 1" (or "job 2" or even "job 3 or 4") with the developers (understandable given Git's history but not as useful to me -- sooner or later all projects cross platforms it seems). Besides, both Mercurial and Bazaar are largely written in Python which I use extensively and that made them interesting to me. Given that all three are used extensively for large projects, whimsical winnowing criteria like this feel safe enough.

I started out with Bazaar, largely because at the time it was easier to find a non-Fink, non-MacPorts installer for it. It was pretty easy to set up and use and the benefits of it's distributed nature were readily apparent -- my favorite productivity trick is to take my laptop somewhere without a net connection and trivially easy branching and versioning while offline were a breath of fresh air to a Perforce expatriot.

But. I've switched to Mercurial. Mercurial now has a non-Fink, non-MacPorts installer as well (maybe it always has). And it has "hg serve". The "hg serve" command starts an ad-hoc web server that you can browse to locally or over a network to get a quick graphical view of your repository. It comes built-in with Mercurial and it works anywhere Mercurial works. Nothing else to install, no half baked GUI clients, just a good, easy to use GUI. It's not a particularly functional UI (you don't use it to check things in for example) but it provides the thing I want most from a VCS UI: the ability to quickly and easy browse through my repository and look at differences between revisions of code. I keep my own code and any third party code I use under source control and the ability to easily look at revisions (color hilighted, full context etc.) is an important aspect of code archeology. Life's too damn short to spend it looking at raw diffs in a terminal window.

So that's why I decided to give Mercurial a try. I wound up sticking with it (at least so far) becuase it was relatively easy to find information (mostly on the Mercurial wiki) on how to use Mercurial on a Mac, in particular it turned out to be very easy to confgure Mercurial to use FileMerge for diffs and, more importantly, merges (I've never been very good at textual merges with the ">>>>" token markers).

Beyond that, using "bzr" or "hg" commands is largely the same with some minor translation required. In the end, though, it was just easier to make Mercurial dovetail with my Mac and my style quickly and with very little fuss.

The rest of this post will describe how I've set up Mercurial. It's quite possible that all of the following can be done with Bazaar and Git just as easily. I'm putting it here so that it will hopefully will save some one who wants to try Mercurial on the Mac some time.

Once you've installed the lastest version of Mercurial on your Mac you'll want to configure it. You'll do this by creating and editing an ~/.hgrc file. Here are the contents of mine:

[ui]
username = Keith Fieldhouse <keith@rex...>

[extensions]
hgext.extdiff =

[extdiff]
cmd.opendiff = opendiff-w

[merge-tools]
filemerge.executable = opendiff-w
filemerge.args = $local $other -ancestor $base -merge $output

The "username" in the [ui] section simply provides a nice username to label changes in your repository with. the "hgext.extdiff =" line simply turns on the "External Diff" extension. While it's labeled an "extension", it comes as part of the Mercurial distribution. The "cmd.opendiff" line tells Mercurial to run the opendiff-w script (see below) when the "hg opendiff" command is used. Simillarly, the commands under [merge-tools] tells Mercurial how to run the same opendiff-w script when it wants to allow you to do a merge.

The opendiff-w script simply runs opendiff (the command line command that starts FileMerge) through a pipe so that it will wait until FileMerge has exited before returning from the command which is the behavior that Mercurial expects from the diff and merge tools. My copy of opendiff-w is kept in /usr/local/bin and looks like this:

#!/bin/sh
opendiff "$@" | cat

Note that all of the above works after installing the Mac OS X version of Mercurial. No further software is required (well, beyond the Mac developer tools themselves). Most of this information can be found at the Mercurial Wiki. This page and this page describe using FileMerge as a diff tool and a merge tool respectively.

Update: For completeness, here is the ".hgignore" file that I typically use:

syntax: glob

.DS_Store
*.swp
*~.nib

build

*.pbxuser
*.perspective
*.perspectivev3

Then, I gave the VMWare Fusion beta a try. This was the seamless operation I was looking for. The install went without a hitch, after installing the VMWare tools the Ubuntu display automatically adjusted to the size of the MacBook display in full screen mode. It's also quite responsive, I can dedicate a decent amount of memory to the instance and copy and paste works. This is very cool. I took advantage of the low price ($39.00) during the beta period and chalked up the $79 I paid for Parallels to experience.