I suppose if the path is relative to some executable, then you could still do that at runtime.
How does an application say something about what it wants before it starts? Do we expect every application developer to write a darwin-specific boot script? Do we force a "boot" script (think something like Twisted's "twistd") for every platform so that things like this can be accommodated?
Well, it's better than nothing. My long-term thinking is that you'd have a platform-specific way to launch an "application plugin" that represents the actual application, in the same way that on Windows you can double-click a .jar file to run a Java application. Once that bootstrap facility is available on the platform, then theoretically a given app can just be launched that way.
But I do see your general point. Clearly library deployment on Darwin is a pain in the rear. I'm glad you're following it, because it's completely over my head at this point.
How about we include a manifest file that includes filename, size, and a hash of the file's contents, and has the author's public key in there somewhere at the top or bottom. A second file, or a SMIME or PGP style wrapper around the manifest file, will contain the hash of the manifest file that is signed by the author's private key.
I like this. Specifically, I like the part that it's a separate and optional file, so it doesn't hold up the base format definition. We just need to be able to define how metadata files like this get included in the format, so that other metadata files (like a Chandler Parcel schema, or a Zope ZCML file) would be includable also. Then, the bdist_plugin command would just package up those files, possibly after optionally generating the signature manifest.
What about something like this:
myplugin.pyplugin metadata/ MANIFEST-1.0 share/ mypackage.zcml purelib/ mypackage/ __init__.py platlib/ os-and-python-version-specific-string/ mypackage/ extmodule.so lib/ os-and-python-version-specific-string/ extmoduledependency.dylib
This should more or less allow for someone to create a "fat" plugin that has platform-specific dependencies, but includes them for multiple platforms.
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:
mypackage/
__init__.py extmodule.so
extmoduledependency.dylib __metadata__/
myplugin-0.1.2/
MANIFEST-1.0
signature.smime (???)
configure.zcmlSince this layout is "safe" to unzip into a common location for multiple plugins (i.e., the metadata won't be overridden by a different package or version thereof). I don't currently see a strong use case for "fat" plugins, as distutils cross-compilation capability is limited, which would make it really hard to build a fat plugin. And you certainly wouldn't want a fat plugin for something like wxPython or Numeric, anyway. :)
We should also say that the filenames in the zip file should encoded as utf-8, so we can support unicode filenames. The zip format itself has no standard for this, and there isn't even a de facto standard.
Sounds good.
_______________________________________________ Distutils-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/distutils-sig
