30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
-
-
+
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
### 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!!!!**
* And it certainly should not reside in externalized ini/json data blobs.
**Or do you want ants? 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.)
(Instead of license blobs everywhere in lieu of proper comments.)
The meta description block incidentally can also serve as packaging control scheme. The <kbd>pack:</kbd> 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.
### argparse config: struct
Similarly to internal plugin configuration settings, the <kbd>config:</kbd> list is now used for ArgumentParser definitions. Fields are slightly remapped to remain in line with regular options.
#config:
{ arg: -D, name: debug, type: bool, description: enable debugging }
{ arg: -e, name: enable[], type: str*, description: add plugin }
It's basically just the extra <kbd>arg:</kbd> field which discerns such entries from standard options. And the <kbd>type:</kbd> may carry an optional quantifier (mapped to argparses' nargs= flag). Or the <kbd>name:</kbd> can indicate a list property with `[]` attached (maps to argparses' append instead of store). Not every argparse peculiarity is provided for though. And using a docopt section would probably be a better option anyway.
|