So this allows people to alter the APIs for their plugins and allows
plugins to verify the API is compatible with the one they expect.
It adds a version property to Plugin classes, and has a SemVer checking
method which can be called from other plugins to verify a plugin against
a particular version.
So this feels like a contentious decision. It'd be awesome to have the
options for the methods stored along-side the methods themselves.
The downside with this is that the thing accessing the configuration
data is always the plugin, so it's the plugin that must have requested
the configuration option. This is also important in case the
description of the configuration option needs modifying for clarity or
providing context for how it will be used.
If the interface changes, all plugins calling the plugin methods will
need updating, so the config options can be updated if necessary.
Note: creation of enumerations can be done using Context.object, which
should allow reference of enumeration members by normal type objects.
If it turns out enumerations are never referenced from types, we can
easily remove the try/except in the Module.object method.
Context.object accepts a template or a string name (and now a type
flag). Module.object only accepts a string (because a template already
has most of the stuff built in and might as well be passed to the
Context.object constructor).
The gotcha here is the absolute flag, which must now be set
appropriately in all cases *except* where the module is constructed
with an offset of 0 (whereby it will have no impact).
Python3.6 introduced it, but annoying the type-checker realizes that
we're using it like any int (ie, A | B) and throws a wobbly. Really
want to see the back of python3.5...
Revert "IntFlag is in python-3.5 by default, it's just if the enum34 package is installed that problems happen."
This reverts commit 17a0e1eac8.
Mike Auty