Richard Jones' Log: Sane Python application packaging: initial solution

This is part three of my continuing adventure in packaging my Python application.

Thanks again for the advice given in response to my last post on Linux-specific application packaging issues. I've decided to leave packaging up to the experts and help them as much as possible. To this end I've:

1. split the installation instructions out of README.txt into INSTALL.txt and put in a notice that the INSTALL.txt is not for regular users,
2. looked into how to best support more organised system package maintainers (the INSTALL.txt is my start at that), and
3. generated stand-alone application downloads for Linux, Windows and OS X.

The approach I've taken for the stand-alone packages is as follows:

1. bundle all of bruce, pyglet, cocos, docutils (including roman.py) and pygments into a library zip file,
2. create a simple script for each O/S to run bruce using that zip file, and
3. create the distribution zip files with those contents alongside the README.txt, HOWTO.txt and PKG-INFO.

Since the examples directory is pretty big I've also created a separate "examples" zip file.

This is implemented as a new setup.py command "build_apps" (as BuildApps.) I didn't use zipfile's PyZipFile but rather implemented my own. PyZipFile only includes compiled modules (.pyc or .pyo). The problem I have with this is that the compiled modules are not compatible across Python minor releases (modules compiled for Python 2.5 are not compatible with 2.6 and vice versa.) I would have to include separate library zip files for each system interpreter I wished to support. After some very simple checks I determined that the performance difference is negligible if I just bundle the original .py files instead.

I wrote "build_apps" so it'd fake being an "sdist" command enabling me to upload the resultant file to the Python Package Index (PyPI). This part is really quite inelegant but I'd like to keep the downloads all in one place. Unfortunately the file listing in PyPI lists the files as "Source" which isn't good. PyPI has no concept of an "application" though.

The Windows and OS X application bundles are completely untested.

I intend to investigate py2app and py2exe in the longer term to produce more system-friendly programs (no need to install Python, have icons, etc) but for now I believe this solution is good enough.