[Pythonmac-SIG] Bundlebuilder--why remove it?

Christopher Barker Chris.Barker at noaa.gov
Wed Dec 9 18:32:53 CET 2009

Kevin Walzer wrote:
> Bundlbuilder 
> doesn't really argvemulation anyway, since hooks for this exist in all 
> the major GUI libraries (Tk, wxPython, and certainly PyObjC).

I actually use argv emulation more for non-gui apps -- a way for folks 
that don't like the command line to do some simple processing with 

However, presumably py2app has the same issue, and if not, whatever 
py2app does could be ported over.

Form my point of view I want something that works and will be supported. 
With Bob I. no longer active in the PythonMac community, py2app has been 
languishing, though Jack Jansen isn't around either, so so has 
BundleBuilder. Ronald has done a great job of fixing the really critical 
bugs -- but he's doing so much else.

So it comes down to: is anyone intending to support either one, and if 
so -- that person gets to choose which! If it were me, I'd choose one 
based on what code base is the most robust and maintianble, rather than 
what happens to work now.

What I'd really like to see is a "grand unification" of executable 
builders: while the actual executable building is platform dependent, 
detection of what modules need to be included, etc, is not, and neither 
is the API for specifying what you need.

There has been some progress in that vein: bbfreeze uses modulgraph from 
the py2aap project. It also support Windows and Linux, and Mac a little 
bit -- the author recently requested that someone take on the Mac 
version -- it's not really his thing, but I don't think any one has.

PyInstaller has a Mac version in SVN that I haven't tried yet.

Are there others?

Maybe putting over efforts behind one of these projects would be more 
fruitful -- we' only need to maintain the mac-specific parts.

> And while bundlebuilder is a less robust tool than py2app,

In what way? I never quite understood its limitations.

> In fact, its simplicity (a single module) make it 
> easier to dig into and patch, something I can't do with py2app.

I agree -- the py2app code is a bit opaque to me too.

 > I also
> understand that bundlebuilder is quirky and a less graceful solution 
> than py2app: you have to do some trial and error to get all the packages 
> bundled in your app.

Frankly, I have to do the same with py2app anyway, for all but trivial apps.

On a related note: I had some thoughts about figuring out what to 
include. AFAICT, all the systems examine the source for imports to 
determine what to include. This used to work pretty well, but it seems 
more and more packages are using more dynamic import methods, and also 
setuptools fatures that result in: 1) not including packages I need and 
2) including all sorts of stuff I don't need -- many, many megabytes!

I've been wondering is the opposite approach would work: rather than 
examining the source, run the app, and examine it to see what got 
imported. This would, of course, might not include some things 
conditionally imported, but if you have decent test coverage, you could 
run it on your test code instead, and get a pretty good list. In 
practice, it seems there is always some hand-work in significant aps anyway.

If you really wanted to be safe, you could do a superset of code 
analysis and run-time analysis, which as I think about it, is a good 
idea -- you wouldn't get anything extra that you weren't getting with 
code analysis anyway.

Would it be as simple as dumping sys.modules after running the app?

> What's the best way to keep bundlebuilder available for Python 3.x? 
> Submit a feature request at the bug tracker? Or separate it out, and 
> submit a PyPi project?

Are you proposing to be the maintainer? I'd say submit patches, and see 
if they are accepted -- if not, then fork it and make a new project.

I wish I could find time to work on it more, but I just haven't -- I 
will probably provide the occasional tiny patch to whichever system I 
end up continuing to use, but I can't really play a major role.

my $0.02


Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

More information about the Pythonmac-SIG mailing list