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

Fri, 02 Jan 2009

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.

Comment by ionel on Fri, 02 Jan 2009

What's the point of uploading bundles that have no resemblance of python packages to pypi since it breaks all the conventions pypi was built on ?

I would not do such a thing - breaking all the tools built on pypi doesn't seem right. Then again - you could upload the bundles on google code or whatever and leave _normal_ packages on pypi.

Comment by Steve on Fri, 02 Jan 2009

Just use executable zip files.

http://www.voidspace.org.uk/python/weblog/arch_d7_2008_12_06.shtml#e1038

Comment by Richard Jones on Fri, 02 Jan 2009

@ionel yeah, hence I said it was inelegant. I just want all my downloads in one place. If I split them up I will have a problem with users grabbing the source because it's the only download immediately visible. Or I host everything on google code, which I'm not so keen on. Maybe I should just get over that.

@Steve I don't think the world is quite ready for a python2.6 dependency.

Comment by ionel on Fri, 02 Jan 2009

Or alleviate the pain by making a setuptools command to upload to googlecode.