Happy 4th!

I know it’s a day late, but I was a little busy yesterday with cooking and guests.

I’d just like to give a shout to the handful of people who read my blog (including those of you who don’t bother posting–ever) to have a happy and safe Independence Day.

I plan on having a few announcements in the coming weeks related to some projects and possibly yet another new layout for the site. This one got old pretty quick!


Links: July 2nd

Yeah, I’m a day late on my links. It’s not that there isn’t much interesting going on, but I’ve been a little busy.

Uh oh, what’s that burning smell?

Google’s AppEngine has been having problems today.

Health is a pain

  • Basic painkillers like Tylenol could be banned due to the liver damage they can cause.

Technology, smells like fish

  • Bruce Schneier spreads word of a new attack against AES. While this doesn’t mean much for the continued security of your data it does remind us that nothing in technology (especially cryptography) is ever static. Be vigilant. That’s good advice, isn’t it?

    As Schneier states:

    While this attack is better than brute force — and some cryptographers will describe the algorithm as “broken” because of it — it is still far, far beyond our capabilities of computation.

    I love his articles.

  • I was going through some backup CDs of mine from years ago (we’re talking 1999–so about 10 years or older) and stumbled across some .ZIPs I had password protected. Unfortunately, I can’t remember the password. Take my advice: If you’re going to password protect some stupid documents that don’t matter a darn to anyone else, make sure it’s something you can easily remember. Maybe even consider writing down the password and stuffing it under the carpet–anything. ‘Cause the fact is, after 10 years, those backups won’t be readable because you won’t be able to remember the password. Plus, you’ll have to look into cracking the password. Fortunately, none of the stuff contained in my passworded .ZIPs is all that interesting to me now. Plus, somewhat humorously, those same files are duplicated elsewhere. At the very least, it’ll give me an excuse to learn plain text attacks against ciphers if I have some time. I’m really curious what password I chose.
  • I neglected to mention that Eclipse Galileo is out. This is probably the most exciting news of the week! I’ve been using it for about four days now, and I’m impressed. It’s a lot more responsive than Ganymede. If you’re going to grab it, consider downloading it from Eclipse Srouce’s Yoxos on-demand installer. Using Yoxos, you can build your own Eclipse distribution complete with the plugins you want. It’s so much easier than hunting plugins down by hand.

PyQt, py2exe, and pyinstaller

As I wrote in a previous installment of my links of the week, I discovered a really nice replacement for py2exe. However, pyinstaller doesn’t seem to play nice with PyQt…

The documentation and mailing lists suggest adding hooks for “hidden imports” in the pyinstaller/hooks directory. I’ve been having problems with this for quite some time:

Traceback (most recent call last):
  File "", line 47, in 
NameError: name 'QtGui' is not defined

Whenever I attempt to run an executable built from my Qt application. I’ve tried creating a hooks-PyQt4.QtGui.py, hooks-PyQt4.QtGui.py, and a number of permutations thereof without much luck. So, I decided to go back to trying out py2exe only to discover that the problem I was having with it was due to a really stupid mistake on my part.

As it turns out, you cannot simply create a setup.py setup script anywhere you like, even during testing. Here’s my application layout (roughly):


I had placed my setup.py under Chatly/chatly/client temporarily in the hopes it’d save some typing when indicating the script path during the build process. ‘Course, if I had been thinking clearly about previous .eggs I’ve built, I should have known this wouldn’t work. Nevertheless, I tried it and ran into this:

D:\python25\lib\distutils\dist.py:263: UserWarning: Unknown distribution option:
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'py2exe'

(Yeah, this is from Windows. Since I’m building a Windows app in Python, it’s a necessity. Cygwin doesn’t work for this in particular, unfortunately. I hate the command prompt–it’s too anemic and lacks the utility of a proper shell.)

Since I’ve always created Python applications in distributable packages (like eggs) the right way, I’ve never experienced this particular error. When I was searching Google for clues, I expected some obvious answer. There weren’t any. Some people discovered they had py2exe installed twice (how?) and others were simply not using the correct arguments passed to setup(). Since my setup.py looked like this:

from setuptools import setup
import py2exe

I was pretty sure that wasn’t a problem. I did read the py2exe documentation, after all.

Then I tried something. I figured that if, perhaps, py2exe were causing a problem, I could simply uninstall it, run the setup.py as it existed, and it’d generate an ImportError, right?

Nope. Same error.

That was when I began to realize it was some rather stupid mistake on my part with the choice of positioning for setup.py. When I moved it to the project root outside any package where it’s supposed to live, it worked fine. Oops.

The problem with building a PyQt application still troubled me, though. The documentation for py2exe is fairly extensive (thankfully), and after some digging around, I discovered that the missing QtGui import–rather, the one that wasn’t working–could be resolved similarly to the _qt issue mentioned in py2exe’s documentation. The result was a setup.py that looks like this:

from setuptools import setup
import py2exe
setup(windows=["chatly/client/ui/qtui.py"], options={"py2exe": {
         "includes": ["sip", "PyQt4.QtGui"]}})

PyQt4.QtGui is required to import the Qt GUI classes since they’re evidently not imported by py2exe’s internals during build. sip is also required (it’s a part of the PyQt build process) and without it, nothing will work.

The finished product is a distributable package that works rather nicely–on Windows.

No comments.