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

Cappuccino is designed to provide an application-like interface inside a web browser. As a result, when you're building a Cappuccino application, instead of the server providing a sequence of pages to view, the server is providing data (usually using JSON) that the Cappuccino application running in the browser retrieves and displays. For all practical purposes, using Cappuccino is very like old-fashioned client server programming with the client written in Objective-J and the server, in this case, written in Python.

In this post we'll focus on changing the Cappuccino "Hello World" application so that it retrieves it's message from the server using JSON. No, it's not a particularly exiting application but it has the virtue of being simple and fundamental: Once it's possible to act on JSON data from the server, the rest is just details.

First, we'll change the client side Objective-J code. We need to add the following two lines to the end applicationDidFinishLauching: method of our AppController in AppController.j

 
    var request = [CPURLRequest requestWithURL:"getLabel"];
    var connection = [CPURLConnection connectionWithRequest:request delegate:self];
 

The first line creates a CPURLRequest for the "getLabel" URL from the server. The second line actually makes the connection to the server using that request object. Like it's inspiration, Cocoa, Cappuccino makes heavy use of the delegate pattern. In this case we pass our AppController object as the delegate for the CPURLConnection. There are two methods that the CPURLConnection may call on the delegate. We'll add those next:

 
- (void)connection:(CPURLConnection) connection didReceiveData:(CPString)data
{
    var result = CPJSObjectCreateWithJSON(data);
    [label setStringValue:result.label]
}
 
- (void)connection:(CPURLConnection)connection didFailWithError:(CPString)error
{
    [label setStringValue:@"Label Did Fail With Error"]
}
 

The method "connection:didReceiveData:" is called with the original connection object (useful to distinguish between multiple pending connections) and the data that the server provided. The "connection:didFailWithError" is called if the connection failed for some reason.

For now, we'll simply change the label when the connection completes. If the connection fails, we'll note that. If the connection does receive data, we'll use that data to change the label. To do this, we use a CPJSObjectCreateWithJSON(data) object. Once we've done that, we can retrieve the "label" attribute of the result and display it.

There's one other thing that we need to do on the client side for all of this to work. In the original AppController.j, the label object is a local variable. Since other methods of our AppController object need to access that object, we need to make it an instance object. We do this by adding the following line to the "@implementation AppController" stanza in AppController.j:

CPTextField label;

We also need to remove the "var" qualifier from the first appearance of the label variable in "applicationDidFinishLaunching:"

The server side is even simpler. We simply need to add a method that will respond to the "getLabel" request that the client will make. We do this by adding a "getLabel"
method to the root CherryPy object:

 
    @cherrypy.expose
    def getLabel(self):
        data = {"label":"Server Hello" }
        return simplejson.dumps(data)
 

In that method, we'll create the Python dictionary that we'll return. It has one attribute/key "label" which we'll set to the string "Server Hello". Then we use the Python simplejson to convert that object to a JSON string which we return.

We've seen that it's fairly easy to communicate between the Cappuccino client and the CherryPy server. Next we'll start looking at building a somewhat more elaborate client application based on data returned from the server.

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

At the time, merge oriented version control was new to us (our experience had been with lock oriented version control). Perforce the company did (and still does) and excellent job of explaining its technology and the strong philisophical underpinnings behind the design choices they made. That, coupled with excellent support duing the eval period (and afterwords) reasonable pricing and very solid software made it easy for us to switch to Perforce -- a decision we never regreted.

Four years ago when I joined a small company that was still using CVS it was remarkably easy to help effect a fairly seamless change to Perforce for much of the same reasons.

These days, though, I look a bit longingly at the distributed version control systems like darcs, mercurial, git and bazaar. To my mind, based somewhat limited experimentation, these distributed systems provide a certain "nimbleness" to the working envionment that dynamic languages provide. In a way, they are to Perforce what Python and Ruby are to Java (though that's an analogy that'd probably break down fairly quickly).

What I wonder is this. If some company with the same "sensible, reliable" style that Peforce had 10 years ago (and still has) delivered a distributed version control system that was as solid, fast and reliable as Perforce, with the same level of documentation and support would Perforce be in trouble? I have to think they would, though the "sensible" part of that proposal is probably less likely than the technical part. Perforce is s company that essentially does one thing, and one thing very well. I admire them for that. But their product hasn't really changed meaningfully in the 8 years that I've been using it, which I think exposes them to some risk.

Which gets me to my wish. The biggest problem with Perforce is that despite several workarounds, it's a pain in the neck to use if you don't have a live reliable connection to the central depot. For remote work, which I do a fair bit of, this means that I either always have my VPN fired up (with the associated cheerful tromping of my typical network environment) or I use one of those less than satisfactory workarounds. And If I happen to be in a cabin on a lake in Maine with no Internet connectivity at all, I'm really out of luck.

I want to be able to take a Perforce client and treat it as (or export it to) a distributed VCS work space. That means that I'd be able to maintain a revision history within my client that's independent of the main repository. That allows me to setup up checkpoints before some risky bug fixing maneuver. I want to be able to push and pull my workspace to colleagues. This allows me to easily set up collaborative efforts or shared bug hunts easily with messing with a lot of repositories. Then, when I've pulled all the merges I want into my initial workspace, I want to be able to commit it back to the Perforce depot. I'd be willing to live with a system where I can only peer with workspaces that were pulled from my initial workspace (dealing with the merge paths that could result from peer merging and then submission from multiple work spaces is too twisty for my head).

I know there a few foo2p4 and p42foo scripts out there that attempt to provide something like what I've described. But none of them seem to be quite ready for prime time (yet) and besides, I want a supported, rock solid solution.

If Perforce doesn't provide something like that, I think someone else will.

Technorati Tags: Scala, Java, Python

Technorati Tags: Ubuntu, Xubuntu, XFce, Linux

Technorati Tags: Smalltalk, WhiskerBrowser, Squeak, Eclipse