from __future__ import * 3.10.2004

ANN: py2app 0.1

py2app is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to py2exe.

Even at this early stage, it's probably the most advanced python packaging utility out there with regard to dependency analysis. It's at a "works for me and the two other people that have tried it" stage. It's not particularly documented, and I don't have time to document it today, but you should be able to get along given the examples. Since it is very similar to py2exe in design, you can also borrow ideas from there.

If you have any issues with py2app, please let me know. Provide source if possible. I'm particularly interested in problematic packages which use import tricks or in-package data files such as PIL or pygame. These two are explicitly supported by the extensible "recipe" mechanism of py2app, but there are surely others. I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things. Until a recipe is created for a particular problematic package, you may always just include it wholesale with the -p argument.

Download and related links are here: http://undefined.org/python/#py2app

py2app kicks it

I've spent some more time with py2app this week, and I'm pretty sure it's way beyond bundlebuilder's capabilities at this point (except for half-assed plugin building). It actually has a significantly smarter scheme for dealing with dependencies than py2exe now. Feel free to borrow it :)

I rewrote the standard library's modulefinder to use a dependency graph (py2app.modulegraph), and I dropped all of that "missing module" craziness. I have never seen a case where the missing module reports were useful at all, so it's gone.

Using a graph allows you to selectively prune dependencies, and it makes adding implicit dependencies much more sane. For example, you definitely don't want a Tkinter dependency just because PIL.Image does "import FixTk" for initialization purposes. However, it's entirely likely that the user might want Tkinter later, so in the PIL recipe I simply remove the PIL.Image -> FixTk dependency. Importing ImageTk, or anything else that depends on Tkinter, will of course cause Tkinter get included.

I have added full package include support, but have not done a no-zip distribution mode. This is of little utility with the full package include mode and alias build mode for development, so I may drop it altogether. If you have a strong opinion about this, state it now, or else it will almost definitely go away.

I have also added an extensible recipe system, and included recipes for PIL and pygame. The PIL recipe is quite complex, because PIL's initialization is. The pygame recipe simply forces it to be included as a full package. The cool thing about py2app's full package support is that it still does mach header rewriting of the extensions it can find (via macholib).