D 2015-04-03T19:09:18.340
L plugin\smeta\sdata
N text/x-markdown
P f375b827c8459e7d810f53a25dc7243573323970
U mario
W 3081
# Plugin meta spec
Streamtuner2 now uses a proper plugin description scheme. Note that this is completely unrelated to the streamtuner2 or channels API, or how plugins are actually initialized (pkgutil, imp, implib, pluginbase/plugnplay).
Basically the top-level comment block is scanned on initialization. It simply lists a few key: values for documentation and technical descriptors. It's basically a subset of YAML embedded in a script comment.
# api: streamtuner2
# type: feature
# title: My Plugin
# description: Lists all the things
# version: 1.0
# category: music
# config: { name: myconf, value: 1, type: boolean, description: enable foo }
#
# And here goes a longer doc/comment.
The key names are case-insensitive of course. A few fields like title:, description: are required. Theoretically also the api: and type:. Though in ST2 they're currently just used for decorative purposes like the category: or version: field.
More interestingly the config: field can be used to describe plugin options. Default values will automatically end up in streamtuners `conf.*` dict, and are presented to users in the config dialog.
* A value: represents the default.
* The type: select can be used for dropdown boxes, with a `select:` key=VAl|key2=VAL2.. attribute for options.
* Other type: values are interpreted as strings, except type: boolean which becomes a checkbox.
* A per-option category: attribute is ignored at the moment.
* Params can be optionally quoted as in value: "Desc, desc, desc." in case they contain commas (which otherwise separate option attrs.)
And of course, the config: field can list multiple options. Simply make it multi-line (every plugin meta field can be) by indenting wrapped lines.
### Why?
This scheme is designed to be language-agnostic. It originated in PHP way back (see [libconfig](http://milki.include-once.org/genericplugins/)), precisely to avoid a few common misdesigns.
* Meta data does **not** belong *in code*.
Because that incurs always importing them, even when they may go uninitialized/unused.
* And it certainly should not reside in externalized ini/json data stores.
**BECAUSE THAT'S HOW YOU GET ANTS!!!!**
* Furthermore it encourages a *useful* documentation block atop.
(Instead of the lazy-bummed Let's-add-the-license-blob-everywhere.)
The meta description block incidentally can also serve as packaging control scheme. The pack: descriptor is used by [fpm/xpm -s src](http://fossil.include-once.org/xpm/wiki/src). Which avoids manually doubling descriptions into separated setup.py/.cfg as the current Python packaging eco system does.
Note though, that the plugin description scheme is primarily intended for *in-application* feature/plugin management. Reducing packaging effort is just a by-effect.
Z eb1b52b26e881b9dfb9043f3a62f98c8