Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Plugin-specified PyB API version constraints #257
Plugins should be able to specify which versions of PyB they are compatible with. If there are breaking changes in the internal PyB APIs, PyB should be able to warn the user that plugin does not support the currently running version of PyB and should discontinue operation.
PyB should use SemVer to indicate compatibility:
Yes agreed. But I'd try to start optimistically and only have plugins indicate a minimum version of PyBuilder (if they so wish).
I don't think a plugin should break by default because there was a major version increment since the incompatible change(s) might not affect the plugin at all.
A minimal version should be enforced though.
I guess some kind of static function that plugins can call à la
from pybuilder.core import declare_plugin declare_plugin.for_api_version("0.14.0").and_greater() # plugin code
would be a good start. Also we need to handle the case where PyBuilder is bootstrapping itself and has not replaced the
I was thinking more along the lines of
pyb_version="<[PEP 0440](https://www.python.org/dev/peps/pep-0440/) version constraint>"
If no version is specified there is no check.
I am not sure I like the complexity this inversion of control introduces.
A library function would allow me as a plugin author to:
These things are important but hard to achieve with declarative style constraints like setting a local in the module toplevel.
I'm not sure where you see the inversion of control here.
The plugin has access to
The case I'm targeting is whether the plugin should be at all initialized within the current build given the running PyB.
Having PEP 0440-style enforcement prevents any of the code (beyond module/package initializer) from running. If the plugin owner decides to use ostrich version checking (i.e. not using
To take a lesson from Mozilla Thunderbird plugins, for example, this is a common situation:
My plugin supports PyB versions 0.13.x but not 0.14.y, therefore
I, as a plugin owner, decide that my plugin will not load with PyB 0.14 cause I have no clue what API changes might come there and don't want to risk incompliant or nonsensical behavior.
Yeah I gave it some more thought and you're right. The library function approach has the showstopper that it's not backwards compatible, whereas declaring a local at the module level is.
I guess I wanted to avoid look-before-you-leap constraints in plugin that lead to build crashes when the plugin would actually work fine, but at this point it's not much more than a crystal ball guess.
Agreed for the pep constraint in