Bob Ippolito (@etrepum) on Haskell, Python, Erlang, JavaScript, etc.
«

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).