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

[Phillip J. Eby]

At 05:16 PM 12/9/04 +0100, Thomas Heller wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
> > 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.
>
>This may even be an idea for single-file py2exe: Let the stub unpack the
>extension, maybe in a TMP directory, open the file with
>FILE_FLAG_DELETE_ON_CLOSE (so we don't have to clean up manually), and
>then let the stub load the extension.

Of course, this code is going to be platform-specific, by necessity.  And, 
it should be configurable, so that an application can define a 
non-temporary "cache" directory for the extraction.  The stub loader should 
check for same file date and size as the archived extension(s), and go for it.

We also need to figure out what to do for non-extension 
libraries.  Presumably py2exe doesn't need to do anything special because 
the libraries just install next to the .exe.  But for .dll or non-Python 
.so files, they'll need to be extracted somewhere.

And, the stub loader support module will also need to be able to do the 
header munging for Mac OS X.

Hm.  Maybe we should just have platform-specific stub loader support, since 
we know the target platform at archive build time.  So there could be 
darwin_stubloader, win32_stubloader, and so on.  We just package the right 
one, and write the stubs accordingly.

But just as 'os' and 'os.path' map to e.g. posix and posixpath, we should 
still have a generic stubloader module API so that an application can be 
platform-agnostic about its configuration.  That is, an app that wants to 
support Darwin will need to set any non-default Darwin options it cares 
about, but it shouldn't need to check the platform and import a different 
module to do that.  The platform-specific stubloaders would all support the 
same API and just ignore configuration specific to other platforms.