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
drag-and-drop.
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
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
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.bar...@noaa.gov
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
