Plumbing Life's Depths

Setting up networking on a remote machine is a bit of a pain.  If you happen to make the smallest of slips your ssh session gets black-holed and you're up it.  You can try using a `shutdown +10 -r` command in another session to reboot-on-failure, but there's always the chance that you forget to set it up right when you need it, right before you bring up a mis-configured interface that messes up your routing tables (duh!).  You can even use the fancy curses UIs if you like, as long as you disable the interface onboot... but again, you have to remember the shutdown command.  Did I mention; "remember to run the bloody shutdown command so you don't have to wait a day for someone to come in and hit `reset`"... that's an important bit.

Marius contributed quite a few changes (restructuring to support VirtualEnv-ing, enhanced percentage reporting), the source-code-view is also there, the home-view is more likely to be reasonable (though it can still get messed up with threaded views).  SquareMap is now explicitly a dependency and has been restructured to work with `setuptools develop` in a virtualenv.  Available off the project page or via easy_install RunSnakeRun (note that you need wxPython installed).

Say you were writing a program that takes a "config-file" parameter and you were (explicitly) passed a filename that, for whatever reason, you couldn't load. Is the proper operation to exit and report an error, log a warning and continue with defaults, or load a default filename silently?

In this particular case, app-armour was configured to prevent dhclient from accessing most of the filesystem. It (app-armour) was dutifully logging errors in /var/log/messages, but dhclient was just silently defaulting back to the very-subtly different default config... queue lots of very subtle debugging effort. Maybe there's some good reason for this behaviour, but at the moment I can't see it.

import this

Have spent rather a lot of time trying to wrestle the deployment docs into shape for the TurboGears 2.1 release.  Even with all that work, only the "standard deployment pattern" is really in "good" shape.  Alternative servers, alternative deployment styles, etceteras are all still needing lots of love.  I am, however, I think, finished with that section for a while unless someone else chips in to help.

Also ran into one of those "argh" inducing issues this evening.  A user was trying to follow through the "Using who.ini" discussion on his way to doing OpenID with TurboGears and ran into a weird, subtle bug.  Turns out, when you disable TurboGears authentication repoze.what "fails open" as far as much TurboGears code is concerned.  The predicates just all silently start evaluating to True.  The @require() decorator thankfully does the right thing, but users who do:

tg.predicates.has_permission('manage')

Now always get a True value (the predicate object), so if you're using that to control display of information... oops.  Not likely to have bitten too many users, but it just seems we should have something raising errors on _nonzero_() if the predicate's aren't "booleanized()".

In other news, given that someone else is trying to get OpenID working, I suppose I should look at the branch of repoze.openid.  Upstream wants changes, but I haven't yet figured out what's supposed to happen wrt registration to make those changes work.  Repoze just doesn't seem to have a registration story AFAICT.

There was a request from one of the RedHat guys to add a source-code view to RunSnakeRun so that users can just flip over to see the code which is running slow when they are exploring a profile.  wx.py makes that pretty easy, so bzr head now supports it.

Want to maybe add a call-tree view.  A memory-profiling view would be nice too, but I don't have a recommended memory profiler at which to point people.  Without that it's a bit of a toss-up as to what memory-profile format to support.

I have just barely managed to keep my "PyOpenGL will have a final release at PyCon" promise.  Honestly I haven't had enough time this afternoon to get much testing done, so I'll have to hold off on a release announcement, but the bytes are out there.  Need to get on a plane in a few hours, and we'll lose network in 45 minutes, so I likely won't get more done for a while.

Luke (of Moksha fame) has been guiding me through the "official" and correct way to do real-time web with TurboGears.  Orbited seems to be a given, but STOMP apparently doesn't scale, while AMQP isn't well supported under Javascript.  That seems to leave XMPP as the likely "official" way until AMQP is fully supported.

Of course, you need an XMPP server to do anything with XMPP, so I'm entering the maze of twisty-turny passages that is configuring EJabberD to connect to our TurboGears database for authentication.  I figure I'll wind up with an external auth script for EJabberD which uses TurboGears command-line configuration to get the DB connection and use the standard friendly-form login table for authentication.  Alternately I could go "wrong school" and just use an RPC call into a TG controller to do the auth, or maybe I could just use a "quick and light" XMPP server for the tutorial and let people struggle with EJabberD themselves (naw, that's not helpful).

However, today, before I get on the plane, I want to release PyOpenGL 3.0.1 final, so robust real-time web-apps for TurboGears are going to remain undocumented for now.