[Pythonmac-SIG] py2app standalone options (original) (raw)

Bob Ippolito bob at redivi.com
Wed Dec 22 00:07:06 CET 2004

On Dec 21, 2004, at 5:42 PM, has wrote:

Chris Barker wrote:

I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments.

First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. For example, appscript currently takes this approach. The lower-level aem package provides a comprehensive wrapper around the AEM; appscript builds on this to provide a nice, safe, friendly-looking user interface for application scripting. Most folks'll just use appscript for all their application scripting, but geeks who need access to the full AEM, e.g. to send asynchronous events, can use aem. Prior to 0.6.0 appscript was a monolithic system, which meant you were SOOL if you wanted to do async events, for example - an issue Bob also happened to raise at the time.

The lower levels at this point, similar to appscript / aem are py2app.create_appbundle / modulegraph.find_modules / macholib.MachOGraph. You can do all the foot shooting you want with them!

To give a practical example, let's say I want to write a GUI interface to py2app. My main dialog has some text fields and checkboxes for basic setup info, plus a table view listing all dependencies, allowing users to check/uncheck the items they want/don't want included. The obvious way to implement this would be to call modulegraph to generate the table content, then take the list of checked items and feed it to py2app's package-building function via an 'includeitems' argument. I really don't want or need py2app to run modulegraph a second time just because it's been welded into the basemost layer.

That's sort of a backwards way to get at it.. given a proper refactoring of py2app, the "dependency finding" and "application building" would simply be split into two separate build phases (which means two command classes and a mess of additional code), so you'd run the dependency resolution phase, manipulate the py2app instance, and then run the build application phase. This is not currently the case, because py2app._run does both. For 0.1.7 I'll at least split this up into more pieces, so it has more useful hooks for subclasses.

If nothing else, a more loosely-coupled architecture takes pressure off the developer to anticipate and support every single possible use to which a user might want/need to put their system and/or its components now or in the future.

Distutils is the antithesis of loosely-coupled architecture. py2app is slowly being split apart into orthogonal components, but this flexibility would add a lot of complexity that I don't want to deal with at this point.

-bob

More information about the Pythonmac-SIG mailing list