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 platform
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.
-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 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
