Greg Ewing wrote:
> I've been thinking for a while about creating something
> simpler that doesn't attempt any automatic module discovery
> at all. You would be required to construct a project file
> that explicitly lists all the required modules and libraries,
> including standard library modules.
I've thought for a while that there is way too much re-invention of the
wheel with the various stand-alone builders. I'd love to see more
flexibility, and ideally code sharing, by breaking down the process into
the various parts:
1) the API for specifying what you need built -- py2app and py2exe at
least share much )but not all) of this, though they are slightly
incompatible. AFAIK, the rest are all different
2) Figuring out what needs to be included. py2app and bbfreeze both use
modulegraph, though bb-freeze apparently forked it.
3) Actually building the bundle -- by definition this will be different
on different platforms, and there are multiple ways of doing it on one
Anyway, ideally, each of these steps could share a common API, and so
each bundle builder could mix and match the parts as they saw fit.
Getting everyone to cooperate is a big social, rather then technical
problem, but py2app at least could be designed to allow each of these
pieces to be replaceable. (maybe it already is -- I haven't poked into
the code enough to know)
So, aside from allowing more code sharing, this approach would make it
easier to plug in different pieces, like Greg's proposed manual
specification of modules.
As for that proposal -- I agree with other posters that that really
would be onerous. However, a hybrid would be great -- run some sort of
automated tool that outputs an easy-to-read-and-edit text file that
could be edited, and have the bundle builder use that. Then you culd
e3dit it, write it frm scratch, whatever you like.
If nothing else, it would really help speed to be able to re-build an
app without having to go through the process of determining what to
include each time. I often find myself modifying the source a bit,
knowing for sure that I haven't changed the dependencies, and then
having to wait for py2app (or py2exe) to do the full analysis again.
Another idea I have for determining what to include is to take the
opposite tack of source-code analysis -- run-time analysis:
You would run your app (or better yet, a test suite), and the tool would
do a run-time examination of what's imported (would that be as simple as
looking in sys.modules?). That way you would capture the dynamic imports
that the source-code analysis misses. You would miss the conditional
imports, but if you have a good test suite, you'd catch those too. (and
if you don't, you'd have identified a hole in your tests). And you would
miss the conditional imports that you really don't want ( I never want
Tk just because I'm using PIL, for instance)
If you really wanted a I-don't-care-how-big-it-is-I-just-want-it-to-work
version, you could use a superset of runt-time and source-code analysis.
I do want to be clear that py2app has been the best bundle builder I've
used, and I really appreciate Ronald's effort to bring it up to speed again.
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