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