[kforge-dev] plugin packaging

[John Bywater]

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
presentation templates
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 
> interface)
>
> So where should plugin config and other stuff go?


In repository:

src/kforge/plugin/[plugin-name]/__init__.py (holding class called Plugin 
which derives from the PluginBase class)
src/kforge/plugin/[plugin-name]/command.py
src/kforge/plugin/[plugin-name]/django/templates/
src/kforge/plugin/[plugin-name]/docs/
src/kforge/plugin/[plugin-name]/dom.py
src/kforge/plugin/[plugin-name]/etc/[plugin-name].conf

or wherever the plugin is being developed.

In installed system:

kforge/plugin/[plugin-name]/__init__.py
etc/plugin/[plugin-name].conf
django/templates/plugin/[plugin-name]/

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.

>
> Proposal
> ========
>
> 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:
>   kforge.plugin.<plugin-name>.Plugin
> 3. config.py file so that you have plugin config in module (how does 
> this work with single module plugins?)
>   kforge.plugin.<plugin_name>.config


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:

<python>
import kforge.plugin

class Plugin(kforge.plugin.PluginBase):
    pass

</python>

such that the following works:

<python>
import kforge.plugin.[name]

kforge.plugin.[name].Plugin()

</python>


Configuration could/should be made to appear in the system dictionary as 
plugin.name.variable. (The PluginBase class holds a reference to the 
system dictionary.)
Templates could/should be loaded from path with prefix: plugin/name/
etc.

John.