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

[Bob Ippolito]

On Dec 8, 2004, at 13:20, Phillip J. Eby wrote:

> 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.

Makes sense.

> 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.

It Just Works as long as you do it the way they want you to (use an 
application bundle or a fixed path relative to the root of the 
filesystem).  Trying to mangle it into doing something it's not 
supposed to do is a pain in the rear, but that's more or less 
universally true.

>>>> 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:
<zip layout incompatible with zipimport>
>> 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:
<zip layout compatible with zipimport>

Uh, why does it matter if zipimport can do something with it if we're 
going to need a custom importer anyway?

By the way, .par is just about the worst possible choice for an 
extension, ever.
- It's already used by Perl and PHP to mean similar things
- Explicit is better than implicit (what the heck is a par?).
- We're not using DOS anymore, it's safe to use more than three letters.
- It's a common english word, good luck finding it on google or 
anywhere else for that matter.
   "pyplugin" has "about 14" results on google (that displays as 4)
   "par" has "about 245,000,000", which looks like just an upper bound 
on the amount of results they're willing to give you.
   Even "par python" has "about 589,000" results.

-bob