[Pythonmac-SIG] Just starting out - Python 2.3.3?

[Bob Ippolito]

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