[kforge-dev] plugin packaging
john.bywater at appropriatesoftwarefoundation.org
Mon Sep 19 15:25:01 UTC 2005
In general, I think this should follow the way, for example, a KForge
package would be installed on a package-based distribution: the
pre-installed files are put into various right places within the system.
A plugin may have:
plugin object (to receive system events): required
extensions to the domain model (ie persisted plugin specific domain objects)
presentation views, forms, and inserts for other views
plugin specific configuration
Rufus Pollock wrote:
> As more plugins get developed we want to start thinking about how
> plugins get packaged and the related question of what files/info
> plugins are expected to supply and where this is installed.
> Example: Plugin Config
> Can't start adding all of plugin configuration to kforge.conf (as we
> have started to with e.g. trac). as:
> * wrong dependency direction: should have plugins -> core not core
> -> plugins
> * this goes back to a very early discussion about whether plugin
> specific config need be available to other parts of the system
> * if does not need to be available we can just put config in with
> plugin and leave it there
> * if it does need to be available then have to install
> configuration into central system dictionary when you install the
> plugin (an alternative is for plugin to support some kind of querying
> So where should plugin config and other stuff go?
src/kforge/plugin/[plugin-name]/__init__.py (holding class called Plugin
which derives from the PluginBase class)
or wherever the plugin is being developed.
In installed system:
I think config should be defined in the same style throughout. So having
plugins use a python module for configuration, when the core system
doesn't seems wrong to me.
> Personally I have a great preference for keeping plugins as
> self-contained and self-sufficient as possible. This means, for
> example, keeping the config with the plugin. This way plugins and the
> core system are as independent as possible.
> Suggestion for files:
> 1. docs:
> * README.txt
> * INSTALL.txt (optional)
> * LICENSE.txt if different from main license
> 2. code modules supplying at minimum:
> 3. config.py file so that you have plugin config in module (how does
> this work with single module plugins?)
It doesn't work. But we make things really flexible and search through
the loaded plugin package for classes which extend PluginBase,
DomainObject, (a future ConfigBase?) etc. and deal with them appropriately.
This would mean that a plugin implementor would just need to define
objects, rather than also conform to strange requirements to load them
onto the core (by naming convention, such as Plugin above, or by method,
such as how the Trac plugin registers the TracProject domain object).
The KForge core could go through the attributes of the package, and use
the first PluginBase extension it finds as the plugin system, register
all DomainObject extensions with the domain model, and place any Config
extension in the system dictionary. That would make the plugin
implementors task much simpler than at present.
> Extra Questions
> QU: Should plugins outside of the kforge namespace be allowed?
> ANS: Current position is no.
I think we should stay with 'no'.
As above, KForge plugins are Python packages that are installed to
kforge.plugin.[name] which contain at least:
such that the following works:
Configuration could/should be made to appear in the system dictionary as
plugin.name.variable. (The PluginBase class holds a reference to the
Templates could/should be loaded from path with prefix: plugin/name/
More information about the kforge-dev