[Pythonmac-SIG] py2app standalone options

[has]

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.

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.

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.

Hope that makes sense,

has
-- 
http://freespace.virgin.net/hamish.sanderson/