On Jan 27, 2005, at 11:26 PM, Richard Jones wrote:
On 28/01/2005, at 2:45 PM, Bob Ippolito wrote:On Jan 27, 2005, at 7:31 PM, Richard Jones wrote:1. I can't find source for PyObjC (though I think it might come with Python?)
Ever tried google? Even clicking "I'm feeling lucky" will take you to the right place.. which happens to be <http://pyobjc.sf.net>.
OK, a fair cop. I just assumed it would be hard to find given it's not linked from pythonmac.org.
It is actually, at the bottom of the front page of http://pythonmac.org/
2. I can't install a --enable-framework in a place other than /usr/local -
the --prefix and INSTALLDIR arguments to --enable-framework appear to be
ignored.
I need the resulting Python to be relocatable (ie. bundled inside a drag-installed app like other OS X apps) ... and I've now got a niggling feeling that this isn't possible...
The /usr/local crap just symlinks inside the framework, so your feeling is not correct.
Hrm. Still doesn't quite address point #2 though. I guess the answer, reading between the next lines, is "it doesn't - just use /usr/local" :)
I don't think you understood me. When you build as --enable-framework, the files installed to /usr/local are simply for convenience of use. The fact that they are in /usr/local is of no consequence and they are not at all used by the framework itself. If you ask what the os.path.realpath(sys.executable) is, it won't say /usr/local.
What you don't realize is that even though it is a framework, it is not really relocatable (in a deterministic fashion at runtime) without jumping through a significant amount of hoops. py2app jumps through these hoops for you, so this isn't a problem. Also, py2app doesn't need nor care about framework vs. non-framework builds.... so, use whatever works best for your application, and py2app will do the rest to make it redistributable.
You will want to use py2app when bundling your application though, as the Mach-O headers need some rewriting in order to avoid conflict. If you start it up with a non-System Python, it will automatically decide that you want to include a stripped down version of the Python runtime inside your application.
.. note that py2app can even do this for a non-framework regular 'old unix-style build. However, those builds don't have the machinery to run GUI applications outside of the context of an application bundle. If you're using PyObjC, you basically need to be using a per-application bundle anyway, so it's really not a problem. py2app's alias bundle mode is great for this, I suggest reading the PyObjC tutorial.
Yeah, I guess I have a whole lotta reading to do. I've opened a can of worms, and they're looking scary :(
Having said that, last time* I did this, PyObjC didn't exist and I'm *pretty* sure it's making my life easier this time, if I can only crack this minor issue of getting Zope up and running in a PyObjC-enabled Python, and then have it bundled, and ... :)
This "can of worms" is simply that the issues with bundling applications for the Mac are all well specified now and have been discussed quite a bit because they are difficult to understand, somewhat non-intuitive, and come up on a regular basis.
Well, PyObjC is a lot older than OS X... so, that's not really correct. Whether a usable port of PyObjC to Mac OS X existed at the time you wrote that app, I'm not sure. I certainly wasn't using it at that time.
py2app does all the things that need to be done in order to make it work. It is far easier than it used to be. Using py2app also happens to be easier than using py2exe, because it has a better understanding of modules and dependencies, so at least it's not any worse than doing the same thing for other platforms.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
