[Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Bob Ippolito]

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