[Distutils] Standardizing distribution of "plugins" for extensible apps

[Phillip J. Eby]

At 09:37 AM 12/8/04 -0500, Bob Ippolito wrote:
>On Dec 8, 2004, at 8:35, Phillip J. Eby wrote:
>>At 11:50 PM 12/7/04 -0500, Bob Ippolito wrote:
>>>Also, if you allow extraction of C extension modules, you'll probably 
>>>also have to allow extraction of dependent dlls and whatnot.. which is a 
>>>real mess.  For dependent dynamic libraries on Darwin, this is a *real* 
>>>mess, because the runtime linker is only affected by environment 
>>>variables at process startup time.  I can only think of two solutions to 
>>>this for Darwin:
>>>(a) build an executable bundle on and execve it on process startup, drop 
>>>the dependent libraries inside that executable bundle
>>>(b) have some drop location for dependent libraries and C extensions and 
>>>rewrite the load commands in them before loading (which may fail if 
>>>there isn't enough wiggle room in the header)
>>
>>With regard to 'b', I'm not quite sure I understand about the rewriting 
>>load commands.  Are you saying that on Darwin, you have no 
>>LD_LIBRARY_PATH?  Because, wouldn't it suffice for the application to 
>>have that defined when it starts, and install the libraries on that 
>>path?  What am I missing, here?
>
>Load commands (runtime dependencies between Mach-O files) have full paths 
>embedded in them, not just names, so that is why header rewriting is 
>useful.  If these load commands start with "@executable_path/", then the 
>first place the library is looked for will be relative to the executable, 
>which makes (a) possible and is what py2app already does when you start 
>including dependencies.

Okay, now I'm really confused.  How the heck does Python manage to load 
dynamic stuff at all, if everything has to have absolute paths in 
them?  Can you use load commands relative to the location of the library 
itself?  And who designed this crazy thing?  ;)


>>IOW, if you have a directory set up on LD_LIBRARY_PATH or its equivalent, 
>>can't you just dump the libraries and C extensions there?
>
>Darwin has a pair of environment variables that are sort-of equivalent to 
>LD_LIBRARY_PATH, however, their values are cached by the runtime linker 
>(dyld) as soon as a process starts.

I meant, couldn't a given application instance just say, "okay, this is 
where I'm going to put my libraries", and have the environment variable set 
before it starts?  That way, it could add new stuff to that directory at 
runtime without needing to restart.

I suppose if the path is relative to some executable, then you could still 
do that at runtime.


>How about we include a manifest file that includes filename, size, and a 
>hash of the file's contents, and has the author's public key in there 
>somewhere at the top or bottom.  A second file, or a SMIME or PGP style 
>wrapper around the manifest file, will contain the hash of the manifest 
>file that is signed by the author's private key.

I like this.  Specifically, I like the part that it's a separate and 
optional file, so it doesn't  hold up the base format definition.  We just 
need to be able to define how metadata files like this get included in the 
format, so that other metadata files (like a Chandler Parcel schema, or a 
Zope ZCML file) would be includable also.  Then, the bdist_plugin command 
would just package up those files, possibly after optionally generating the 
signature manifest.