Present Perfect

I usually tend to think of Python as the discerning gentleman's programming language: well-behaved, well-documented, people take care of the code written. I like the batteries-included approach and assume that the battery code in the standard library is well-written. "import this" is a vision statement directly included in the language - it's hard to get more stylish than that.

I got an eye-opener this weekend however. I was still on my quest to get desktopcouch and ubuntuone working on Fedora. While wresting with this bug and doing things that I usually consider a hanging offense (changing /usr-installed code by adding prints to figure out where the craziness was coming from) I finally drilled down to the exception-raising reason. It all boiled down to a single line of code in httplib.py:

def __init__(self, host, port=None, key_file=None, cert_file=None,
strict=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT):

where socket.py contains

_GLOBAL_DEFAULT_TIMEOUT = object()


So, in a nutshell, httplib2.py tracebacks because of this new object, which isn't a valid argument to sock.settimeout()

Now, I'm pretty sure I'm running into this problem because I'm doing "bad" things to some of the stdlib, pulling in bits I need to make ubuntuone (coded on a 2.6.3 python where my Fedora 11 comes with 2.6) work.

But pulling the cover off like this did point out this one object that:

• seems to be intended to be private, but it gets referenced from other stdlib modules
• comes with no documentation at all
• comes with not a single comment explaining *why* it's there, or *why* it's ok to just create a completely empty and useless "object" that you can't even trace the origin of (I had to override __setattr__ on some class to figure out what the anonymous object was, and where it was being set from, to find it)

Maybe I'm oldfashioned, but this leaves me disappointed. This one line breaks beauty, explicitness, and readability that is included in the Zen of Python.

The only attempt at explaining I found is this.

Any Python guru want to set me straight on why this isn't the incredibly ugly wart on stdlib that I consider it to be ?

Meanwhile I'll go digging in svn to see when it was added to 2.6 and why.

I usually tend to think of Python as the discerning gentleman's programming language: well-behaved, well-documented, people take care of the code written. I like the batteries-included approach and assume that...

Once in a while one is allowed to gloat at a job well done, right ?

I just read this favourable review of our codecs and DVD player. It reminds me we've come a long way over these past almost-six years. I'm happy to see that someone I don't even know has such nice things to say about our work.

Which only goes to show that, the less I'm involved with a particular area of work at the company, the better it seems to do :)

In related news, recently I noticed we took another step on the Ladder of a Real Software Company: we made an Actual Physical Product that you can actually use to install something.

Front: 71128
Interior: 71131

This CD, even though it's already outdated, is going on the shelf at home. After I show it to my mom so she starts believing there is a real company over there in Spain :)

Once in a while one is allowed to gloat at a job well done, right ? I just read this favourable review of our codecs and DVD player. It reminds...

I hacked some more this evening on getting UbuntuOne running on my Fedora 11 desktop.

Now, obviously, trying to get something with 'Ubuntu' in the name on Fedora was going to be an exercise in masochism, so I pretty much knew what I was in for.

The good thing though is that the desktopcouch and ubuntuone hackers are obviously enthusiastic at someone getting this to run on Fedora, and as I often find the right motivation is 75% of the work. If these guys are going to be receptive to my feedback, then it is worth spending my time getting this to run.

I needed to first figure out order of packages and software. ubuntuone-storage-protocol goes underneath everything. For now I settled on creating a bdist_rpm out of the setup.py, which I should repackage properly later.

On top of that goes the ubuntuone-client stuff.

Here's a bread crumb trail of bugs I ran into with possible patches I made:

• ubuntuone-storage-protocol 1.0 release does not have pem file in MANIFEST
• ubuntuone poking into httplib.HTTPSConnection private variables which weren't there before 2.6.3 (Fedora 11 has 2.6, which I assume is the release right before 2.6.1 :))
• a bug where ssl authentication fails, because the ca-certs.crt of Ubuntu is a completely different path on Fedora - but that took a while to figure out because of the obtuse error message

Now I got it to the point where the client applet actually starts up without errors, and loads a UbuntuOne page into my Firefox window:

And there are no further tracebacks on my console.

Sadly, I get this puzzling notification message straight after:

I'm not sure yet how my client can be newer - I'm sure the ubuntuone guys will tell me what this means. Enough hacking for one day, time to catch some sleep for tomorrow.

UPDATE: apparently I ran into this bug, where apparently due to some bug the ubuntuone guys decided to add a capability to make sure no one would be using the old client. I understand the logic but I think that should be handled better - the message is not obvious, and I don't think it's easy to figure out what's wrong.

In any case, the patch worked for me, and I just synced my first test file to the cloud ! Whee ! Not sure why syncing a 22 byte text file took roughly half a minute to sync, but it's a start.

I hacked some more this evening on getting UbuntuOne running on my Fedora 11 desktop. Now, obviously, trying to get something with 'Ubuntu' in the name on Fedora was going...

Time to unravel some tufts of the yak hair lying around from this weekend.

I wanted to work on making my GTD application (using CouchDB) a little more friendly.

I started out by learning GreaseMonkey so I could modify Trac pages to include a link converting the ticket into a thing in my application.

The basics of that were easy, but I need to learn a bunch more Javascript before it will actually work well. So, I switched to finally figuring out if desktopcouch might be a good solution for the general problem for users to set up a couchdb database.

desktopcouch's tagline describes it nicely 'A CouchDB for every desktop.' From what I can tell, it has:

• a way to automatically start a per-user couchdb instance
• oauth enabled by default for it, so only you can get to it
• some gnomekeyring integration
• a pairing tool that makes it easy to pair with other desktopcouch instances on your network
• a python module on top of python-couchdb that layers a 'record' concept over CouchDB documents using record_type and record_revision keys
• some pre-defined record types for notes, contacts, and bookmarks
• possible integration with the UbuntuOne service

At this point I don't know how intertwined this record concept is with the rest of desktopcouch. As at the moment I want to use desktopcouch simply as a reliable way to get a secure, per-user, replicated couchdb database, I'd prefer to not deal with records at all at this point.

In the process of getting acquainted with desktopcouch and packaging it for Fedora, I ran into a few little niggles:

• First off, bdist_rpm didn't work for desktopcouch because of the man pages being compressed.
• My first run failed. Furthermore, the unhandled exception left my $HOME/.local/share/desktopcouch in a half-done state; I ran it again, and it worked, but it didn't generate a couchdb.html as it should have because of this.
• Some rpmlint warnings

As for the package, if you're on Fedora 11, just install tao-release for F-11 i386 then type 'yum -y install desktopcouch'

After that, you can start it by asking it for what port is running:


dbus-send --session --dest=org.desktopcouch.CouchDB --print-reply --type=method_call / org.desktopcouch.CouchDB.getPort


If all goes well that should come back with a number.

You can now access your desktopcouch through Futon with:

firefox $HOME/.local/share/desktop-couch/couchdb.html


Let me know if this worked for you or not !

I have a separate post about packaging ubuntuone stuff, which was much more complicated - and I'm still not sure if I will be able to use it as an online server for my couchdb app.

Now, for some questions to you desktopcouch-savvy people out there:

• Looking at the generated couchdb.html, I see that I can now access the user-specific couchdb with a generated username and password. If I want to push my GTD app to this couchdb, I can do so using this username and password. So, obvious questions: a) should I push with couchapp this way to get my app in desktopcouch ? b) is there a better way to get this username/password ? I assume desktopcouch does this in the python modules using gnome-keyring c) is it an intended mode of operation to be able to push my app into the user couchdb ? I am working on the web interface part served by couchdb and I want it to be one of the ways in which to access the data.

Is it possible to pair with a different user on the same machine ? I was on a laptop with no other linux computer around, so I was not able to test the pairing. I did set it up for a different user, but neither account seemed to see the other's couchdb running.

• Will I be able to sync non-record databases to ubuntuone ? If not, what else could I do to have an online couchdb to sync between my various work machines ?

Time to unravel some tufts of the yak hair lying around from this weekend. I wanted to work on making my GTD application (using CouchDB) a little more friendly. I...

Today while using bdist_rpm to build a quick package to test desktopcouch, the build failed on man pages. It took a while to figure out what to google for, but it turns out it's this bug which will turn 7 years old come Friday.

That is a little embarassing. I don't know if it's because bdist_rpm hardly ever gets used or because it's hard to figure out what the bug is or how to report it.

In any case, I attached a patch that worked for me today against python 2.6. I punted on actually rebuilding Python for Fedora for my repo since it's a little bit overkill (the plan is to build a proper .spec file anyway for the package), but if you need the patch it's in the bug report.

Today while using bdist_rpm to build a quick package to test desktopcouch, the build failed on man pages. It took a while to figure out what to google for, but...