Bob Ippolito wrote:
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.
One of py2app's goals is to integrate seamlessly with distutils and to behave similarly to py2exe when it makes sense. That goal is counter to making it suitable for inclusion into a GUI workflow, unless that GUI's job is simply to piece together a setup.py script (which is completely orthogonal to what py2app does). Distutils isn't very good at pausing in the middle of a command, and py2app executes as a single distutils command, therefore what you specifically mentioned is not reasonable.
Hmmm. I see your point. Perhaps somebody should tell the Disutils developers that MVC isn't just for Christmas? (Oh wait... I remember already sounding out the DU SIG - doing the canary-in-the-coalmine bit, as it were - but they seemed distinctly disinterested in rethinking its approach. Just grown too comfortable with their monolithic tower, I think.)
The goal for 0.2.0, which I think has already been achieved (sans documentation), was to make it better than the alternatives for any platform.
When do you think we'll start seeing some formal documentation for py2app?
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.
In order for that to happen, either every user will have to have every version of every library already installed, or they would have to have the newest version of every library already installed (assuming that libraries would never be able to break backwards compatibility).
Hardly. All you need is a CPAN-style central repository and a runtime extension that knows how to look it up and download components on-demand.
You can already have that if you want it, but none of them are perfect and none of them are suitable for the common user on Mac OS X.
Which is not to say that such a system could not be made suitable for the common user. All it needs is a will, and a really solid grasp of HCI (something OSS often isn't as strong on, but that's not insoluble either).
Why should an application developer even have to bother listing its "requirements"?
Developer shouldn't. That's what tools like modulegraph are for.
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.
Honestly I can't see how you can really complain about setup.py being "complicated":
I assume Ronald was referring to setup.py in general, rather than to py2app's setup scripts (which don't lug around the gobs of static data that module/extension setup scripts do).
...
Anyway, I think it's probably time this thread was cut loose; with MacPython 2.4 looming I think folk've got more useful stuff to be talking about right now. Will leave the last word to anyone that wants it. :)
Regards,
has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
