>> 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.
_______________________________________________ Distutils-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/distutils-sig
