On Mon, Aug 2, 2010 at 6:37 AM, Tarek Ziadé email@example.com wrote:
Here's a proposal to extend PEP 376 to support a basic plugins feature -- you should read PEP 376 before reading this mail
It's basically Phillip's entry points, but with an activation flag, and a per-user config file.
= adding a PLUGINS file =
A new file called 'PLUGINS' is added to the dist-info directory at install time, and contains a list of plugins for the installed distribution.
The file is a CSV file like the RECORD file, containing one plugin per line. (see the RECORD file for details on the syntax)
A plugin is defined by :
- an application name : a string containing a name of a group of
plugins. It can be the name of the application that supports plugins, or any string. The recommended value is the distutils name of the project, as it appears at PyPI. max length: 64, chars: [a-z0-9]
- a plugin type name: a string containing a name of a type of plugins.
It can be combined with the application name to create one class of plugins for a given application. 64 chars [a-z0-9] -- default value 'plugin'
- a name: a string containing a name for the plugin. Combined with the
application name and plugin type, it defines this plugin. 64 chars [a-z0-9]
a description: a string describing the plugin. 256 chars.
a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated
a code link: a link to the plugin object (whether its a module,
class, object, etc). This link is the complete import path. For example, a plugin class called "Foo" located in the "bar" module, located in the "baz" package, is noted: "baz.bar.Foo" (the project that uses plugins is responsible for iteratting, picking and loading plugins)
Is dealing with name conflicts left up to the application?