[Pythonmac-SIG] py2app standalone options
bob at redivi.com
Fri Dec 17 23:20:01 CET 2004
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
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
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
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
> 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:
> 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
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
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!
More information about the Pythonmac-SIG