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/
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to