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

Phillip J. Eby pje at telecommunity.com
Wed Dec 8 14:44:24 CET 2004

At 12:20 AM 12/8/04 -0500, Mike Taylor wrote:
>I'm also interested in this idea.  While I'm new to the distutils scene, I 
>am currently tasked with creating installation tools for Chandler so maybe 
>I can be of some help.

Great, that saves me the trouble of waving down an OSAF person to get 
involved.  :)

>On Dec 7, 2004, at 11:50 PM, Bob Ippolito wrote:
>>How about some kind of public key as well, so that if you visit the 
>>update URL you will know if the new package was provided by the same 
>>author or not?
>Some sort of signature, or other means of validation, would be a must - 
>otherwise the security risk would make cross-site scripting attacks look 
>enjoyable :)

No more so than with any other current technique for installing Python 
modules, but nonetheless a signature mechanism is a "nice-to-have" at the 
current level of things.  I'd like to leave a way open for that, but not 
allow it to hold up implementation of a basic format, so that we can start 
experimenting with its use.

>The only issue I see with versioning would be if you have a plugin that is 
>operating specific - then the version information would need to include 
>that metadata.

Platform dependency for C extensions, plus general OS platform dependencies 
should be part of the metadata, but they don't need versioning, except e.g. 
OS version dependencies.

>I took a good look at how to make Chandler be able to use existing 
>modules/libraries in order to reduce the number of included dependencies 
>and ended up putting the idea down and just backing slowly away from 
>it.  Without the metadata information that this idea would provide it just 
>seems to be one big mess.

Indeed.  In the general case, a "plugin" under this concept could easily 
just be a bdist_plugin of an arbitrary package, however, like Twisted or 
wxPython.  Granted, they might have to tweak the setup scripts a little in 
order to properly enable it, but once the format exists, a lot of other 
things should be possible.  For example, if you have a pure-Python 
application with no C extensions, but you depend on packages that do have C 
extensions, you could just bundle platform-specific plugin distros of those 
other packages, built by people with access to the target platform.

More information about the Distutils-SIG mailing list