Older blog entries for RickMuller (starting at number 46)

The Python Distutils are one of the nicer features about Python, as they allow one to build, install, and distribute Python modules.

I'm in the process of trying to build RH9/FC1/FC2 RPMs using the distutils for the PyOpenGL module, and am having problems.

First, the distutils builds more than one version of the RPM file (a debug version and a non-debug version), and then dies on a simple AssertionError when it finds more than one version. As seen here, the distutils mailing list has known about this for over a year, and I don't know why it hasn't been fixed. Obviously, one can simply hack bdist_rpm.py, but I don't want to do this, in part because I want to be able to make sure that people who use my software can install/upgrade things without hacking their python installation.

Secondly, when calling bdist_rpm, one is supposed to be able to pass in --python=whatever arguments to specify which version of Python one is building the RPM for. This doesn't seem to work, and, additionally, seems to kill other options.

It has been a while. I note that my last post was complaining about Debian. Actually, it was praising Debian as much as complaining about it. There are some amazing things about Debian. The user community is unparalleled, both in the sheer number of packages submitted to the archives, and to the help they can offer. And apt is similarly brilliant. But the rate at which stable releases come out is much too slow, and I got tired of living on the edge with Sid.

So I tried out Fedora Core 2 this weekend, and I've been amazed. Fedora, in conjunction with fedora.us, provides a great set of stable packages, and yum is working pretty nicely as a replacement for apt (although I realize that I can use apt/synaptic with FC).

Debian
Debian is a remarkable mix of contradictions. Debian has a remarkable package management system, probably the best linux package management in existence. At the same time, the political battles are unbelievable frustrating and threaten to marginalize the package. Recent resolutions to remove all non-free documentation and firmware from the install mean that Sarge will be delayed until 2005. Woody, the last release, came out in 2002, which means that people using the "stable" (i.e. Woody) branch of Debian have packages that are all several years old, which is a problem for some of us. Now, I realize that anyone can simply can upgrade their installation to "testing" (i.e. Sarge) quite easily, but the fact is that most casual users won't do this. Plus, part of the "cool" factor of any distro is having reasonably up-to-date packages.

That being said, I just did a major reinstall on my home box using Sid, and I am once again floored by how easy it is to maintain a Debian box. I have a hard time using other distros now, since Debian is so effortless.

Is the Software Pricing Model Part of the Problem? I was recently musing about the wonderful Emacs program. Emacs is so stable that most of the time I don't even know which version of the program I'm using anymore. The program has changed very little over the past 10 years because it already includes most of the functionality that most of the people need.

In contrast, Microsoft Word changes drastically every 3 years or so, even though it already contains more functionality than most people will ever use. Why is this the case? Perhaps MS Word changes because MS doesn't get paid unless people buy new versions of the software, so they bloat their code adding more and more features to lure customers to upgrade.

I've always been against the idea of software subscription pricing, mainly because when I buy a piece of code, I want it in my greedy little hands. I want the CD, and, if possible, the source code. However, it occurs to me that the software that I do license (mostly techno stuff like Matlab) is much more stable than the software I buy. Ditto for the free software like Emacs.

Perhaps the idea of buying software is the problem. MS has wanted for a long time to move to a subscription model, and I've always seen this as another attempt to grab more money and power. But perhaps if they were to sell software subscriptions, the MS programmers could spend their time improving the base product rather than chasing creeping featurism.

My interest in wxPython continues. I've now released PyCheckbook as a wxPython application.

Movies Saw Eternal Sunshine of the Spotless Mind over the weekend, and haven't enjoyed a movie this much in years.

Python and Graphics Posted a question to comp.lang.python a while back, and got some good responses on it. I'm looking for a set of widgets that play nice with OpenGL and have cross-platform support in Python. The responses to the posting led me to wxpython, and I've been playing around with it, mostly by making my PyCheckbook program work with wxpython.

Thus far I'm really impressed, particularly with wxGlade, the builder for wxpython, which I find even nicer than Glade.

But even apart from wxGlade, wxpython has a nice professional feel to it, like it was designed rather than just thrown together. I'm really enjoying it thus far.

Well, it's official: Spaulding Gray is really dead. I had hoped that the preliminary reports of this were somehow false. Sad that a brilliant man is gone.

A few interesting links today:

A Byte of Python is an introductory Python text that is released under a Creative Commons license.

Hey, coffee is a health drink!

PyOpenGL: I recently came across the following error while building PyOGL on RH9.0 under both Python 2.2 and 2.3.2 warning: error while loading Togl.so: can't find package Tk 8.1 'setup.py build' worked fine, I only saw this error upon running 'setup.py install'. I'm running Tk8.3, so I don't know why it's looking for 8.1. I've built PyOGL on Mac OS X/fink and RH8.0 and have never before seen this problem. I googled the error and found a couple of other occurances of this error (e.g. here), but no suggested work arounds.

Got a response to this from Mike Fletcher, who referred me to this web page, where Craig Kaplan posts the following:

 
 One of your brave fellow students provided her laptop in what 
 proved to be a successful PyOpenGL linux building experience. 
 Here are some simple instructions.  They should work for, say, 
 RedHat 8/9 and Python 2.2 or 2.3.  I'll assume you're using 
 Python2.2 for these instructions -- the substitutions for 2.3 
 should be obvious. 
  
   1. tar xzvf PyOpenGL-2.0.1.07.tar.gz 
      cd PyOpenGL-2.0.1.07 
      python setup.py install 
  
 At this point we'll get to that mysterious "can't find Tcl 8.1" 
 error that some of you have experienced.  But a lot of the 
 files we need have already been installed. 
  
   4. Edit the file "setup/togl_setup.py".  Look for the lines 
  
       # make package index for tcl/tk 
       if not dry_run: 
  
      Change "if not dry_run:" to "if 0:" to disable the block of 
      code that follows. 
  
   5. Edit the file 
      "/usr/lib/python2.2/site-packages/OpenGL/Tk/linux2-tk8.3/pkgIndex.tcl" 
      (the name may be slightly different for you).  Add the following lines 
      to the end of it: 
  
 ------------ CUT HERE -------------- 
 if {![package vsatisfies [package provide Tcl] 8]} {return} 
 package ifneeded Togl 1.6.0 \ 
      [list load [file join $dir Togl.so] Togl] 
 ------------ CUT HERE -------------- 
  
   6. Go back to the PyOpenGL-2.0.1.07 directory and re-run 
      "python setup.py install".  This time the installation should 
      run until the end. 
  
   7. Don't try to test that it works from within the PyOpenGL 
      source directory -- it fails for some reason.  Switch to 
      a different directory and try "from OpenGL.Tk import *" 
      from within a Python session.  You shouldn't get any errors, 
      and a small window should appear on the screen. 

Python editors:

Found a thread on Python editors in this article. Made me think a bit about my own environment, which is Emacs with the Emacs Python Mode, which I'm happy with. But I'd be interested in an editor that supported folding, such as SciTe, Leo, or the PythonCard Editor. This Page has an extensive list and links to all editors. There's a thread here about implementing a folding mode in emacs, which is probably the way I'll have to go, since I'm too much of a mossback to change drastically.

37 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!