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