[Pythonmac-SIG] Python C extensions that depend on dynamic libraries

[Bob Ippolito]

On Jan 12, 2004, at 3:56 AM, Nicholas Riley wrote:

> On Mon, Jan 12, 2004 at 03:50:52AM -0500, Bob Ippolito wrote:
>> Well, it's pretty obvious they're not folders, so I wouldn't be
>> confused.
>
> Sure, but you're hardly typical.

Yeah, but most people have never seen a ".bundle" file or folder either 
way, so that's why I used myself as the example.

>> Just as a semi-but-not-really-serious idea:  I wouldn't complain if
>> they *were* folders (CFBundle-type-bundles) on the Mac.  Think about
>> it, we could embed the particular version of Python and OS
>> compatibility matrix in the Info.plist, throw in some fun external 
>> data
>> into Resources, put required dylibs/frameworks in Frameworks (and the
>> Python runtime could jigger the appropriate dyld incantations to make
>> them load properly), use a higher level plugin API then raw dyld,
>> whatever.  It's a metadata party, and everyone is invited.
>
> As an optional thing this sounds fine, but flat MH_BUNDLE containers
> should be supported for equivalence with every other Python platform.

To further encourage people to built bundles by hand with the wrong 
tools or linker flags?  ;)  I suppose it's necessary to maintain the 
MH_BUNDLE aspect -- not because of "equivalence" -- but because some 
useful software programs insist on Not Using Distutils (subversion, and 
uh.. VTK maybe?).

>>> What's wrong with using '.so' as the extention?
>>
>> .so probably implies MH_DYLIB?  I don't really have a problem with 
>> .so.
>>  It's ".pyext" that I don't really like.
>
> .so doesn't seem to imply MH_DYLIB, especially given the example of
> Apache.  There's no difference between dylibs and bundles under other
> OSes, "shared object" doesn't seem to me to connote one or the other.

It implies MH_DYLIB to me because when you're porting software, more 
often than not, a ".so" on Linux is a ".dylib" in OS X, and even if 
it's ported as a ".framework" it's still MH_DYLIB.  Maybe it's just me. 
  Yes, I'm aware that other operating systems don't have separate header 
layouts for "dynamically linked libraries" and "plugins"... I'm just 
thinking statistically here, so that probably means I'm wrong.

> I don't have a huge problem with .so either, but I'd prefer something
> more specific like .pyext.  Why are you against it?

I think .pyext is more confusing (or at least less aesthetically 
pleasing) than .bundle for No Good Reason.  I think .bundle would be 
ok, because that's what Perl and Ruby use.  In other situations, 
.bundle is sometimes a plug-in bundle.. but in our case, Python 
extensions are plug-ins, so the difference is only technical.  As far 
as I know, those are the only two other "Python equivalent" 
interpreters distributed with OS X.. so we're all alone here.  I don't 
want to count TCL, and especially not Java, because it seems they're 
smoking something we're not with regard to MH_BUNDLE vs. MH_DYLIB and 
file name extension consistency.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040112/da5a3827/smime.bin