Differences between version dated 2004-12-07 22:31:46 and 2004-12-07 22:40:10
Deletions are marked like this.
Additions are marked like this.
#format rst
(Draft, preparatory to sending to the Distutils-SIG)
(Sent to the Distutils-SIG)
Many applications need or want to be able to support extension via dynamic installation of "plugin" code, such as Zope Products, Chandler Parcels, and WSGI servers' "application" objects. Frequently, these plugins may require access to other plugins or to libraries of other Python code. Currently, application platforms must create their own binary formats to address their specific requirements, but these formats are of course specific to the platform and not portable, so it's not possible to package a third-party module just once, and deploy it in any Python application platform.
* a distutils "bdist" command to package a set of modules in this format
* A PEP 302 importer that supports running of code directly from plugin distributions, and which can be configured to install or extract C extension modules. (This will serve as a base for platform developers to create their platform-specific plugin registries, installation mechanisms, etc.)
* A PEP 302 importer that supports running of code directly from plugin distributions, and which can be configured to install or extract C extension modules. (This will serve as a base for platform developers to create their platform-specific plugin registries, installation mechanisms, etc., although there will be opportunity for standardization/code sharing at this level, too.)
* additions to setup() metadata to support declaration of:
* ability to specify metadata files to be included in the distribution, that are specific to the target application platform (e.g. Zope config files, Chandler parcel schemas, WSGI deployment configuration, etc.)
(This is actually only "level 1" of the standardization that I'd like to do; levels 2 and 3 would address runtime issues like startup/shutdown of plugins, automatic dependency resolution, isolation between plugins, and mediated service discovery and service management across plugins. However, these other levels aren't necessarily germane to the distutils, except insofar as those levels influence requirements for the first level. Also, it's important to note that even without those higher levels of standardization, the availability of a "plug and play" distribution format should be beneficial to the Python community, in making it easier for applications to bundle arbitrary libraries. Indeed, tools like py2exe and py2app might grow the ability to automatically "link" bundles needed by an application.)
(This is actually only "level 1" of the standardization that I'd like to do; levels 2 and 3 would address runtime issues like startup/shutdown of plugins, automatic dependency resolution, isolation between plugins, and mediated service discovery and service management across plugins. However, these other levels are distinct deliverables that don't necessarily relate to the distutils, except insofar as those levels may influence requirements for the first level. Also, it's important to note that even without those higher levels of standardization, the availability of a "plug and play" distribution format should be beneficial to the Python community, in making it easier for applications to bundle arbitrary libraries. Indeed, tools like py2exe and py2app might grow the ability to automatically "link" bundles needed by an application, and there will likely be many other spin-off uses of this technology once it's available.)
My main idea is to expand the existing PKG-INFO format, adding some formally-defined fields for system processing. These fields should be validated, and the distutils should not produce a plugin package with invalid data in those fields. The specific kinds of metadata needed (that I know of currently) are:
My main idea is to expand the existing PKG-INFO format, adding some formally-defined fields for system processing, that are supplied by the setup script or in additional files. The additional metadata should be syntactically validated (and semantically, to the extent possible), and the distutils should not knowingly produce a plugin package with invalid execution metadata. The specific kinds of metadata needed (that I know of currently) are:
* Static imports (module names and specification of compatible versions)
* Dynamic imports (wildcard masks)
Anyway, I would see the deliverables here as being a PEP documenting the format, a prototype implementation in setuptools (for current Python versions), migrating to an official implementation in the distutils for Python 2.5. I'd like to find out "who's with me" at this stage in having an interest in any aspect of this project, especially if you have requirements or issues I haven't thought of. Thanks!
