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

[Phillip J. Eby]

At 01:32 PM 12/9/04 +0100, Thomas Heller wrote:
> >> 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?
>
>If you use a custom importer, it could extract extension modules to the
>file system on demand (for those non-hypotetical platforms where it's
>required).  And it may even be possible with zipimporter, if the archive
>has some custom extension loaders.

That's actually a good point; py2exe does basically that now, with a pure 
Python stub replacing the extension.

Of course, py2exe relies on the extension and its libraries being outside 
the archive.

Hm.  Does the normal Python search look for extensions first or 
second?  I'm just wondering if unzipping an archive with such stubs would 
automatically work when Python does its normal import mechanism.  That is, 
would the extension take precedence over the stub?  If so, then that 
approach is a real winner.  bdist_plugin (or whatever it's called) could 
create stubs that provide extension loading support, and which would be 
ignored if the archive was unpacked.  If need be, a support module could be 
included in the archive's root, so that the stubs don't have to be large.

In fact, if the support module allows controlling policy for how/where to 
unpack extensions for dynamic loading, then an application that wants to 
control that stuff can just include and import the support module directly, 
configuring it for its needs before any plugins with extensions get loaded.

For later Python versions (2.5), the support module would be part of the 
stdlib, and would no longer need to be distributed inside the archives 
produced.  We'd only distribute it for plugins produced with older (<2.5) 
Pythons, and then only if the archive contains extensions.