[Pythonmac-SIG] py2app standalone options

has hengist.podd at virgin.net
Sun Dec 26 16:46:08 CET 2004


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/


More information about the Pythonmac-SIG mailing list