[Pythonmac-SIG] py2app standalone options

[Bob Ippolito]

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