[Pythonmac-SIG] bundle-builder suggestion

[Bob Ippolito]

On Mar 19, 2004, at 12:33 PM, Chris Barker wrote:

> Bob Ippolito wrote:
>
>> It does not make sense to bloat executables because it MAY OR MAY NOT 
>> support an operating system that will not be released for quite a few 
>> months.
>
> Isn't it the developers decision whether it makes sense to bloat 
> executables or not? Personally, I'm fine with expecting that I might 
> need to re-build th bundle in the future, but I'm amazed at the nubmer 
> of little apps we have around here that were written and compiled on 
> Mac-OS System 7, or whatever, and people expect them to work now. Some 
> of them are even pre-PPC.

And I bet none of them include dynamic OS libraries that were provided 
by Apple, also :)

> I'd like to think that Python will be treated by Apple as any other 
> system library, and they maintain backwork compatibility in future 
> versions of the OS, but given what they have done with it so far, I 
> doubt it. At least until Apple uses it far more heavily themselves.

I agree.

>   --standalone leads people to believe that it's compatible with
>> PREVIOUS versions of OS X, and it most certainly IS NOT when used in 
>> conjunction with a Python (and Python extensions) built on OS X 10.3 
>> using standard means, especially the one that comes with the OS.
>
> I don't expect that. I'd never expect a executable built on a given 
> system to work on older systems without doing something special when 
> building it. It's that same with any old C program compiled on 10.3, 
> unless you explicitly build with the compatible libraries, it's not 
> going to work on older systems.

If only everyone else were as experienced and sensible as you :)

>>> I see this as analogous to dynamic vs static linking.
>
>> Yes, exactly, and if you want it to be (roughly) equivalent to static 
>> linking than you better use a Python that you have control over!
>
> I agree, but my understanding is that you create quite a mess if you 
> try to run another Python 2.3.* on an OS-X 10.3 system. We're all 
> hoping for that to get better in the future (indeed, I understand 
> you're working hard to make that happen). For now though, I don't see 
> the problem with including Apples 2.3.0 python in a bundle...do you 
> think it is likely not to work on future versions of OS-X?

The way things are built, especially with the existing bundlebuilder, I 
do not trust it to work properly.  I'm not going to allow the 
bundlebuilder replacement to do it, because if it did have the 
"feature" people would use it.  I will never enable this feature, 
because if you really want it to be standalone you should use your own 
Python.

I'm relatively certain that Python 2.3 will still be current for the OS 
X 10.4 release, so there is no reason to doubt that a compatible Python 
2.3 framework will be included.  The higher point version will be 
binary compatible with existing software and extensions, and the move 
towards -undefined dynamic_lookup will not prevent existing software or 
(--semi-standalone'ed) extensions from working.

Having multiple versions of Python on the same machine and expecting it 
to work properly probably will not ever happen for versions of OS X 
prior to 10.3 (however, this is not a problem in practice).  The OS X 
10.3 (and later) situation could be fixed by adopting the -undefined 
dynamic_lookup linker flag for all installed versions of Python, 
assuming they have the same ABI (i.e. non-debugging Python).  This can 
be modified in-place (with root access or by an Apple software update) 
on the system version.  It's unlikely Apple will do this (though I have 
filed a bug + patch), so you will have to sudo and fix it yourself, and 
then you should rebuild all of your extension modules (just the 
/Library/Python ones).  As for new versions of Python, the linker flags 
can be fixed before you do ./configure.  I don't have the time right 
now to spell this out or support it, though.

-bob