[Distutils] Standardizing distribution of "plugins" for
Phillip J. Eby
pje at telecommunity.com
Wed Dec 8 19:20:23 CET 2004
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
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:
>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:
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.
More information about the Distutils-SIG