[Pythonmac-SIG] py2app standalone options

[has]

Ronald Oussoren wrote:

>>First, I'm  a little unclear on what exactly Has wants. Could you clarify?
>>
>>Freedom, basically. I
>
><rant>
>You obviously don't want it badly enough. Adding an option that will 
>make the application not include stuff from site-packages is not 
>much work, the patch is less that 100 lines (context-diff) and it 
>took me less than half an hour to write it.
></rant>

Oh, absolutely true. But then, given the choice of puddling around in 
py2app's guts for days on end - remember, I'm nothing like as 
technically capable as folks like Bob and yourself - or getting on 
with my own projects, I have to give the latter priority (since who 
else is gonna do it for me?). For now, I can just continue futzing 
with/occasionally swearing at BundleBuilder; it's not ideal, but it 
does the job and lets me get on with more pressing work (like punting 
AppleScript's scrawny old butt to the kerb;).


>>To give a practical example, let's say I want to write a GUI 
>>interface to py2app.
>
>That's an application with different requirements than py2app,

Not sure how: both are intended to build applications, and allow 
users to configure exactly how they're built. The only thing that 
differs is the workflow's order.


>and that should be easy enough to build using the building blocks of py2app.

That would be my hope. Of course, one shouldn't have to disassemble 
py2app with a hammer in order to get at the bits you need; that's my 
concern.


<aside>
Look at all this another way: in an ideal world, developers and their 
applications wouldn't need to deal with any of this dependency crap 
_at all_. Each app would merely list its requirements and the system 
would magically conjour up suitable components upon request. That 
every single app has to lug around its own set of potentially 
obsolete/buggy/system-incompatible dependencies is no doubt partly 
due to this not being an ideal world, so compromises must sometimes 
be made. But then, it might also be partly due to a "well that's the 
way things have always been done" philosophy that's come from the 
traditional 
static-inflexible-early-bound-language-plus-compile-time-linking side 
of computer evolution; constraints Python isn't bound by. Dunno about 
you, but personally I'd want to hedge my bets before tying users down 
to any particular strategy.

Here's another whacky idea: why not get rid of the one-way 
source-code->build->finished-application workflow, and treat [certain 
types of] applications as simply another editable format? This is 
what AppleScript does, for example: write a script and save it as an 
applet, run it, drop the applet onto Script Editor, edit it some 
more, run it, etc. If it errors, a dialog pops up with an error 
description and an 'Edit Script' button that, when clicked, opens the 
script in SE for you with the faulty line already highlighted. 
Emulate Smalltalk a bit more, C a bit less. The more open, flexible 
and neutral tools like py2app are, the easier this kind of lunacy is 
to indulge. After all an idea is only stupid until you've tried it 
and find you really quite like it. :)
</aside>

>BTW. the GUI I'd like to see is a GUI that allows me to grafically 
>construct setup.py files.

I think the biggest problem with setup.py files is that they're 
unnecessarily complicated. The best way to simplify the setup process 
would be to simplify setup.py itself: push all the descriptive stuff 
- name, version, author, description, etc, etc. - into its own 
plaintext file so the only thing setup.py then has to deal with is 
any custom build code. Make the system simple enough that it doesn't 
require a wizard in the first place; a drag-n-drop GUI shell is then 
merely a pleasant (and newbie-friendly) convenience, rather than an 
awkward band-aid for deeper inadequacies.


OK, enough blathering the now... back to getting the next version of 
appscript fit to ship - don't still want to be doing it in 2006. ;)

Later,

has
(May not know much about programming, but I know what I like.;)
-- 
http://freespace.virgin.net/hamish.sanderson/