Apologies for the more gentile readers for this niche technical post, but I’m hoping to solve my technical brothers and sisters some frustrations with Trac, the excellent open source issue tracking system (we’ve been using it for more than 2 years to manage our work with Yankee Publishing, and it’s been truly transformational).
If you’re upgrading from Trac 0.11 to Trac 0.12 and you’re using Trac with Apache and mod_python you might find that after you upgrade you either get a “500 Internal Server Error” form Apache when you visit Trac or, if you have mod_python debugging on (or if you look in your Apache error log), an error message ImportError: No module named trac.
And yet you think that Trac actually is there: you can use trac-admin from the command line, and if you look where you think Trac should be (say, perhaps, in /usr/lib/python2.4/site-packages), you find that it is indeed there.
What’s going on?
It seems that Trac 0.12, at least when I installed it, installs itself as a “zipped egg.” I realized this was true when, after I did:
I ended up with a file (not a directory) in /usr/lib/python2.4/site-packages. My earlier versions of Trac were directories, not files. This, and this helpful post that says, in part:
mod_python 3.x is still unable to import modules from .zipped .egg-files. Command-line python (even older version 2.4 which is included into RHEL5/CentOS5) imports modules from zipped eggs without any problem, but not mod_python for the same version because it overrides the standard importer in its own special way.
So, in other words, Trac is there, it’s just that mod_python can’t see it because it’s zipped. Once I knew this, the solution was easy:
easy_install --always-unzip Trac-0.12b1.zip
Installing this way ensures that the resulting egg isn’t zipped, and once I did this Trac 0.12 ran without issue.