Ask HN: Mac Python "Build Applet": how does it work?
Specifically, I'm really curious what its tiny Python binary is doing, because I may need to replace that myself.
I'll start by saying that I have Googled this to death, and experimented, and I am out of ideas; it is not that I am being too lazy to look elsewhere. :)
The basic problem I face is that applets now embed a binary that is inherently non-portable. On 10.6, it is apparently built in the new default way, which is to require new compressed system libraries. This makes it fast and functional on 10.6, and unusable on 10.5/Intel as far as I can test.
My research suggests that if I could rebuild an equivalent version of this binary in a certain way, the result would be portable to older systems.
I will also say that I've tried not using the binary. After all, Mac bundles are not really rocket science; most of "Build Applet" could be done in some other way. But the tiny binary appears to fulfill a critical role: it ensures that the bundle is identified properly by the system.
For example, if I force /usr/bin/python instead, the system acts as if the whole application is in the bundle "org.python.pythonapp", instead of whatever "com.foo.bar" is requested in my bundle's .plist file. On the Mac, this kind of renaming will completely break anything that searches for auxiliary files (not to mention treat 1, 10, or 50 Python bundles as if they were all the same application).
My use of "Build Applet" is as recent as Leopard. In 10.4 and earlier, the system didn't care how you ran Python, and bundles worked beautifully. I have submitted bugs with Apple requesting that this behavior be improved, that have been ignored.