Present Perfect

One of my tasks for Nerd Night was to set up OpenID authentication on my trac so that the other nerds can log in and change the wiki.

Now, there are two OpenID plugins for trac - an unmaintained one for Trac 0.10, and a maintained one for Trac 0.11

In the past, upgrading Trac minor versions has always been a bit of a pain, especially given the number of additional plugins I usually have installed. But I am motivated, because I want to make the same jump on the office Tracs soon, so that we can configure our workflow - one of the new features of Trac 0.11.

After a half-assed attempt at trying the old plugin last week, I decided to try and upgrade to Trac 0.11 for real, and finish this task. And I decided to do it in a more methodological way than the usual try-and-die. Or, in other words - it's yak shaving time, baby.

I started by updating my draft hacking notes to 0.11, and making them work with an uninstalled Trac.

Then, on my F-9 desktop, I downloaded source of Trac 0.11.1 and the authopenid plugin. I followed my hacking instructions, updating them as I went, and ran tracd with the authopenid plugin uninstalled without problems.

But our hosted server still runs Fedora Core 4 (Wiebe, is our new server ordered yet ?) so I had to build packages for that version of Fedora. So, I created a new tao directory in my repository of packages, for packages I will be only offering on my own website. I forked spec files for Trac, python-pygments, python-textile, and python-genshi. I updated the Trac one to 0.11.1, and the others I backported to work on FC4.

Then, I created all packages using mach, and encountered a small bug in it that Julien introduced when he added a fix for the problem with different people in the mach group trying to build packages. I worked around that with Another Small Hack, then rebuilt the packages.

I tried out these new packages inside a chroot of mach, by running:

mach -r f4e setup
mach -r f4e yum -y install trac
mach -r f4e chroot

And I again followed my HACKING instructions, but this time the installed ones.

I re-used my hackish python-openid package from last week, and tried to build an rpm of the OpenID plugin. Using

python setup.py bdist_rpm

failed however - for some reason, the templates and css files do not get packaged. Same when running sdist instead of bdist_rpm. So I settled for bdist_egg, and copied the .egg file in the plugins/ directory.

Now, trying to log in, I got a traceback. Googling for it brought me to this trac ticket.

A

yum install python-sqlite2

solved it, though I have no idea why! The traceback is completely obtuse, and I don't see how installing something would fix it, but hey... Now I could confirm that the OpenID plugin for authentication worked.

Now, final step, do the actual Trac upgrade on my hosted server!

First of all, take a backup. Luckily, I take daily backups with some script, so it's just a matter of executing the script once more. Upgrade the trac RPM. Do a trac-admin (path) upgrade on all my trac installations. Try them out. So far so good - everything seems to be more or less working, bar some macros that I will need to rewrite.

Then, configure the authopenid plugin. It failed with a traceback that said that the table 'oid_nonces' had 2 colums, and the query was trying to insert 3 values. So I whipped out sqlite3 and compared the schemas between my mach Fedora 4 chroot and my online server. I am assuming that the old OpenID trac plugin created two tables with the exact same name (oid_nonces and oid_associations), but with different schemas. And there is nothing in the authopenid plugin that checks if the schemas are right. So, I dropped the tables, imported the schemas from the chroot sqlite db (handy feature of sqlite3, the .schema command), and bam! Login finally worked!

Not the easiest 4 hour task, but finally completed! On to the next Nerd Night.

One of my tasks for Nerd Night was to set up OpenID authentication on my trac so that the other nerds can log in and change the wiki. Now, there...

It took a lot more work than I expected, but I finally integrated the last of my pychecker patches into CVS just now.

This was a rather embarassing bug where pychecker would 'forget' about all warnings for A/C.py and B/C.py just because both files pretend to be a module called 'C' and pychecker was using sys.modules as a base for tracking stuff. Since pychecker imports all file arguments as a toplevel module, this clashes.

I created a unittest-based testsuite for pychecker, added a test for this particular case, then integrated my previous patch. I ran into an annoying problem though - some other tests now failed from the old testsuite.

Turns out that the code that checks if subclasses call up to superclass __init__ methods was using sys.modules to get to the code object and see if it was called. Since my patch now cleans up sys.modules from all these ad-hoc modules for the file arguments, this wasn't working anymore.

So I created a new module in pychecker to track all PyCheckerModule objects, and use that instead. They're tracked by module name and directory that module name can be loaded from.

It took a while originally before I realized pychecker had this bug - in Flumotion we have a lot of similarly-named files for different components, for example admin_gtk.py

PyChecker never caught any bug in these until I figured this bug out and created a patch.

So, I think I have now integrated all my 2 year old patches for pychecker, just in time for Neal's tentative code freeze. Yes, pychecker is actually going to get a release very soon! No more building custom packages for our contributors.

I'll leave the final testing for tomorrow.

It took a lot more work than I expected, but I finally integrated the last of my pychecker patches into CVS just now. This was a rather embarassing bug where...

In a "Functional Programming in Python" talk, and the author has decided to "remove the return statement from all examples for readibility."

So all of the examples are wrong, and 7 characters are removed while the monster functional statements on the right of the eliminated return statement are still there. Somehow I fail to see how this achieved more readability.

Of course it only took getting to the second slide for someone to raise a hand and say "didn't you forgot to put return in there?" to which the presenter replied "yes, I just told you I wasn't showing them for readability."

Something went wrong there.

Side note - why are all functional programming examples about prime numbers ? Fetishists.

In a "Functional Programming in Python" talk, and the author has decided to "remove the return statement from all examples for readibility." So all of the examples are wrong, and...

to see Google has the same meeting room scheduling problems as we have. During Guido's keynote, a bunch of people came into his conference room claiming they had a reservation. One guy even said "this is Thursday". Not sure if he meant today is (it's not) or if Guido's reservation is...

We actually used to use Google Calendar for scheduling the meeting room, but now there's only a handful of people that can change that particular calendar, and those people have to synchronize by hand to the paper version.

to see Google has the same meeting room scheduling problems as we have. During Guido's keynote, a bunch of people came into his conference room claiming they had a reservation....

In Guido's keynote talk atm - sadly through videoconferencing, though the quality is acceptable.

Apparently Python has backticks in the syntax. I had no idea. But it just does a repr() on the object, so not sure why this was considered special enough to merit its own syntax. I've only learnt about it because it's one of the things being removed for Python 3000. So I guess that answers my doubt.

In Guido's keynote talk atm - sadly through videoconferencing, though the quality is acceptable. Apparently Python has backticks in the syntax. I had no idea. But it just does a...