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

[Phillip J. Eby]

At 12:19 PM 12/8/04 -0500, Bob Ippolito wrote:
>>I suppose if the path is relative to some executable, then you could 
>>still do that at runtime.
>
>How does an application say something about what it wants before it 
>starts?  Do we expect every application developer to write a 
>darwin-specific boot script?  Do we force a "boot" script (think something 
>like Twisted's "twistd") for every platform so that things like this can 
>be accommodated?

Well, it's better than nothing.  My long-term thinking is that you'd have a 
platform-specific way to launch an "application plugin" that represents the 
actual application, in the same way that on Windows you can double-click a 
.jar file to run a Java application.  Once that bootstrap facility is 
available on the platform, then theoretically a given app can just be 
launched that way.

But I do see your general point.  Clearly library deployment on Darwin is a 
pain in the rear.  I'm glad you're following it, because it's completely 
over my head at this point.




>>>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.
>
>What about something like this:
>
>myplugin.pyplugin
>     metadata/
>         MANIFEST-1.0
>     share/
>         mypackage.zcml
>     purelib/
>         mypackage/
>             __init__.py
>     platlib/
>         os-and-python-version-specific-string/
>             mypackage/
>                 extmodule.so
>     lib/
>         os-and-python-version-specific-string/
>             extmoduledependency.dylib
>
>This should more or less allow for someone to create a "fat" plugin that 
>has platform-specific dependencies, but includes them for multiple platforms.

I'd prefer to be able to use a plugin archive (.par, anyone?) directly with 
zipimport in the case that it's a pure Python archive (or if it's on some 
hypothetical platform that can load extensions from a zipfile).  Ideally, 
also, one should also be able to unzip a .par directly into site-packages 
or a subdirectory thereof and use it.  Thus, I'd prefer to see an internal 
layout that's something more like:

     mypackage/
        __init__.py

     extmodule.so
     extmoduledependency.dylib

     __metadata__/
        myplugin-0.1.2/
           MANIFEST-1.0
           signature.smime   (???)
           configure.zcml

Since this layout is "safe" to unzip into a common location for multiple 
plugins (i.e., the metadata won't be overridden by a different package or 
version thereof).  I don't currently see a strong use case for "fat" 
plugins, as distutils cross-compilation capability is limited, which would 
make it really hard to build a fat plugin.  And you certainly wouldn't want 
a fat plugin for something like wxPython or Numeric, anyway.  :)


>We should also say that the filenames in the zip file should encoded as 
>utf-8, so we can support unicode filenames.  The zip format itself has no 
>standard for this, and there isn't even a de facto standard.

Sounds good.