On Dec 29, 2004, at 11:58 AM, Kevin Walzer wrote:
I'm curious about whether BuildApplet and PythonIDE will be included in the next iteration of MacPython, or whether these will be replaced by py2app and PyOxide. Although I know these are old technologies, especially BuildApplet, I'd like to request that they be retained, even if they're not updated or enhanced.
Nothing is going away anytime soon. I'm sure your concerns will be addressed by the time this is even an issue, assuming that you are willing to request features and report bugs to py2app.
The reason I'm asking is that I make extensive use of BuildApplet in the
packages I maintain. I've had inconsistent luck with BundleBuilder,
py2app, and py2applet--mostly bad luck.
If you give up on reporting issues and whatnot with py2app it's not ever going to suit your needs.
py2app's alias build mode (-A) is equivalent to what BuildApplet does *except* the output isn't *ever* portable to other machines because it keeps references not copies to the scripts and data files. It works perfectly fine for "from IDE" use.
The nice thing about BuildApplet that it is, in fact, very simple, even
dumb, in creating applications: it saves the script in question, that's
it. It then becomes a simple matter to add the additional scripts that
come with an application to the app bundle in the appropriate directory,
to edit the info.plist file, to change the icon, etc.
In short, I have control over almost the entire process of packaging. And I've documented this process pretty thoroughly at my website.
Adding dependencies by hand is really sketchy. In order to do it right, it basically has to be all or nothing (until py2app has an interactive mode anyway). Right now py2app's "nothing" option is not portable to other machines. However since py2app alias bundles are so quick to create and the output is so small you can just make one at the destination machine. Which of course, already has "everything", including py2app.
It is not even possible to correctly include the following, very common, kinds of dependencies after-the-fact:
1. Are compiled with an unpatched Python or
2. Are compiled in a 10.2 compatible way
3. Depend on third party dylibs
By "not even possible" I mean that you won't do it correctly unless you REALLY know what you are doing with install_name_tool, etc. If you did, you would probably rather had py2app do it for you anyway, because I guarantee it's not any fun.
I realize there are tradeoffs with this approach. Apps I bundle with
BuildApplet don't have their external dependencies included (wxPython,
PyQt, whatever). But if those external dependencies are installed on the
~ user machine, then the BuildApplet process works flawlessly.
That's an extremely big if and is only really relevant if you're distributing software to other Python developers or inside of a controlled organization.
py2app's alias mode works a lot like that, except it's not portable to other machines because aliases and symlinks are used internally. However, in both scenarios where BuildApplet's output is useful, this is actually reasonable. Python developers can type "python setup.py py2app -A" themselves. In a controlled organization, this could be done as part of the installation process for your application, since py2app and everything else will already be installed by other means.
py2app is a lot more elegant and smarter in what it does in terms of
packaging, but it's also more complex. That is, if there's an error,
it's very hard--at least for me--to debug. The build process dies. I
tested this yesterday with both py2app and py2applet with Eric3, an
application I have successfully with BuildApplet. With both py2app and
py2applet, something didn't get included, even though Bob has now added
PyQt support to py2app. Neither he nor I could figure out what the
problem was. The result was that the bundle created with py2app crashed,
while py2applet just died during the build process.
If you want "stupid" output from py2app, pass --site-packages. This means your applications will work locally, since the missing modules will be searched for in the normal manner, but your application now has a high probability of not working on another machine. Hopefully it's obvious why this is not the default.
Since you were unwilling to even post the results of my suggestion yesterday, implicating me in "neither he nor I could figure out..." is a bad way to put it. Basically, you haven't yet done anything beyond your initial message to help me figure it out, and are throwing your hands up because I didn't immediately know what kind of craziness is involved in Eric3 and how that affects py2app off the top of my head.
That said, the way to solve this problem is to create a setup.py and tweak the includes option until the application has everything it needs. Write down which modules you had to add, and then figure out why the heck they were missing. If it turns out that this happened due to something in PyQt, not the application, then I can make py2app automatically work around whatever stupid import trick caused this to fail for PyQt from the recipe that currently deals with other sip-specific garbage.
This isn't a complaint about py2app: I've tested it with simpler applications and it works beautifully. By all means, it should be the featured method for packaging apps in MacPython. But if BuildApplet and PythonIDE can be retained, even if it's deprecated, that would be enormously helpful to me.
A workable alternative would be if Glenn Andreas continued to include support for BuildApplet in PyOxide. Glenn, is this possible?
py2app is a better choice than BuildApplet for PyOxide. Adding support for BuildApplet before or in addition to py2app seems backwards. Adding support for alias mode is definitely important for something like PyOxide, which would suit your use case (aside from machine portability), and machine portability with a stupid bundle isn't really very useful or important, as I mentioned above.
Perhaps in the future py2app will have a mode similar to alias mode that makes the stupidest dependency-free "self-contained" bundle that could possibly work (locally), but I am still unconvinced that this is more useful than dangerous and confusing.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
