[Pythonmac-SIG] py2app standalone options

[Bob Ippolito]

On Dec 17, 2004, at 3:59 PM, 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?

I think he just wants full control and is either not satisfied with the 
performance or modulegraph or doesn't trust it to do the right thing.  
Which is fine, but I don't really care.  I'm more concerned about doing 
the right thing the majority of the time than accommodating strange 
requests.  I have ideas about a refactoring at *some point* that would 
suit his use case, but it's still in the don't-really-need-it phase so 
it's not going to happen any time soon.

Essentially, I may abstract the dependency analysis to plugins.  
Currently there are two mostly-but-not-really independent dependency 
analysis tools in py2app: macholib and modulegraph, which analyze 
Mach-O object files and Python bytecode respectively (the 
interdependency is introduced by py2app, not either of these packages, 
and that's because Python extensions are Mach-O object files).  In 
"py2app 3000" the whole idea of dependency analysis will be abstract 
which would allow for cached dependency graphs or static dependency 
lists, analyzing code from other languages and architectures (Perl, 
Java, TCL, ELF, and other forms of brain damage I'm sure).  But, again, 
this is a don't-really-need-it feature, so I 
may-not-actually-ever-implement-it.

I imagine what is actually happening for him is that he is writing lots 
of little single-script applications that depend on some combination of 
his packages (appscript, aem, etc.), and for some reason, adding 
--site-packages --semi-standalone 
--excludes=appscript,aem,osaterminology,osax,LaunchServices (via 
commandline or options=dict(py2app=dict(...))) rubs him the wrong way.  
His problem with this method is probably only on a 
theoretical/philosophical level, since that invocation will effectively 
do exactly what he wants, but is not "optimal" because it does do a 
full dependency analysis of everything else it sees.  Maybe his 
computer is really slow?  I don't know.

> I know what I want, I think what Bob has done accomidates this very 
> well.
>
> If you want an app that will run on the machine you developed it on, 
> the Alias option is perfect.

I wouldn't say that it's "perfect", but it does usually do the right 
thing in practice :)

> If you want to deploy an app to other users, but either know or expect 
> them to have a bunch of stuff installed into their Python, you don't 
> want it all included by Py2App. However, I realized that it is highly 
> unlikely that your users will have the exact same installation as you 
> do, so it's best to be explicte about what they need installed, and 
> those things you specify to be excluded by Py2App. I, for instance, 
> expect my users to have:
>
> wxPython
> PIL
> Numeric
>
> Installed, so I can exclude those, but I'd  rather not inadvertantly 
> create a dependence on an obscure package I forgot I had used.
>
> If you want to deliver some code with the idea that users are 
> completely on their own about dependencies, then just deliver the 
> code, and let them run Py2app themselves, if need be.
>
> So, the only use case I can think of for what Has is asking for is one 
> where you want to deliver an app to users that are guaranteed to have 
> EVERYTHING that the developer has installed. This does, indeed, sound 
> like a rare use case to me.

The largest reason I think Has' proposed option causes problems beyond 
what you've already mentioned is that is absolutely requires every 
single Python module and extension to be explicitly stated as an 
include.  Currently you just point py2app at the main script and expect 
it to do the right thing (or at least something approaching that, 
depending on how crazy the code you're analyzing is).  In the situation 
where dependency tracking is turned off, not only will you miss third 
party libraries and extensions that live on your sys.path, but you'll 
also miss modules and packages inside your application's source tree.

py2app tries very hard, by default, to make the Python environment 
consistent regardless of what the end user has done to their system.  
This includes stomping on any PYTHONPATH and ignoring any site-packages 
that the user has.  Due to this, the developer, on their development 
machine, can be reasonably certain that their application will run 
anywhere (for a reasonable expectation of anywhere) if it runs at all.  
So if modulegraph DID miss something, then the developer will know 
about it before he even tries running the application on another 
machine.

Maybe I am doing a little too much forced-hand-holding and insulting 
the developer's intelligence a bit, but given the issues that I've seen 
with similar solutions (particularly py2exe and bundlebuilder) and the 
general lack of "appreciation" for the myriad of subtle ways you can 
bork a Python installation on the Mac, I think this is the right 
solution.

If you don't want an application packager that does the right thing 
more often than not, feel free to use bundlebuilder.  If you want a 
feature in py2app that I don't want to implement, you're going to have 
to implement it yourself, make an astoundingly good case for it and 
change my mind, or attempt to bribe me :)  I perform a public service, 
but I'm not a public servant!

-bob