the serpent, the apple, and Joe

For better or worse, the one application of mine that people actually use is the one I wrote pretty casually with Python over a couple weekends from bed because I was too lazy or hungover to get moving on those days. That software, PubMed2XL [http://blog.humaneguitarist.org/projects/pubmed2xl], lets people do a few things with downloaded citations from PubMed.gov that isn't currently offered directly from the site. I've gotten some nice feedback from librarians, researchers, and information-y people at companies that have found it useful. This post isn't a plug though; it's more an acknowledgement of something that I didn't really realize in full at the time. And that is when one writes software that people go on to actually use, one better be prepared to support it. Now, the software's simple enough that there haven't been real bugs save one [http://blog.humaneguitarist.org/2011/03/16/dealing-with-a-pubmed2xl-bug/], but it does eat at me that I can't offer a simple way for it to work on multiple platforms. While the Windows version is really easy to setup - thanks to py2exe [http://www.py2exe.org/] and Inno Setup [http://www.youtube.com/watch?v=wP9HcD4oPDw] - getting it running on Linux is a bit more work, given all the distro variations and dependency installation. But getting it running on a Mac - particularly with an easy to use installer - isn't going to be possible unless I can find someone to compile it for a Mac who will also test it and compile future versions. Sure, there's the possibility of using Wine [http://www.winehq.org/], but that's still asking a lot from end users. Normally, I wouldn't care. Apple doesn't make it easy for people to develop for Macs unless you fork over the change for a Mac - and I ain't buying a copy of OSX and doing the Hackintosh bit. But, since the software is ultimately about health-related research, I do care. Unfortunately I made - with the advantage of hindsight - two coding decisions that create problems. First, I chose PyQT [http://www.riverbankcomputing.co.uk/software/pyqt/intro] as the GUI toolkit for the software simply because it looks prettier than Python's native Tkinter. My reasoning at the time was the people were more likely to trust better looking software even though it's just a small window with some basic menu options. Eventually, I added a progress bar, too, so downgrading to Tkinter has become less of an option. Second (and this is the big one), I used lxml [http://lxml.de/] since the PubMed2XL setup files [http://blog.humaneguitarist.org/projects/pubmed2xl/#Changing] employ XSL to tell the software what data to put in a spreadsheet cell. Granted, lxml is freakin' fantastic, but since it's not a pure Python module I can't just distribute it in a folder and import the module locally. Not that I had much of a choice: there's no built in XSLT-capable module that ships with Python 'far as I know. So I've been asking myself how to make the serpent (Python) and the apple (OSX) get along. I've consider just making PubMed2XL a web-app, but that will entail expenses for me that simply offering people a desktop app doesn't entail. So, I think the solution lies in a cup of Joe [http://h2g2.com/dna/h2g2/A1300410]. That's to say that a Java app is the obvious solution, specifically using Jython [http://www.jython.org/]. That would leave me to replace PyQT with Swing. I'm fine with that. It's not like PyQT is all that Pythonic [http://www.python.org/dev/peps/pep-0020/] in the first place. There's a nice Jython/Swing tutorial here [http://zetcode.com/tutorials/jythonswingtutorial/]. And as for the XSLT component, this [http://jython.xhaus.com/transforming-with-xslt-on-google-appengine-and-jython/] tutorial on XSLT with Jython and native Java libraries should help immensely. So, I should be able to use Jython to make a cross-platform version of PubMed2XL. I don't necessarily want to, but given the type of research I'd like to help facilitate (in a very small way, I know), I think I probably should.