Rob Crittenden wrote:
Pavel Zůna wrote:
Since there weren't any comments on my proposal about plugin
versioning and dependencies, I decided to make a first implementation,
that shows what I had in mind.
Sorry, I had looked at it and never responded. Seeing an implementation
does help though :-)
This patch adds two class variables to plugable.Plugin: VERSION and
DEPENDENCIES. VERSION is supposed to be a tuple with 2 ints specifying
the plugin major and minor version number. DEPENDENCIES is supposed to
be a tuple of tuples. The inner tuples will contain the plugin class
name (as a string) and a major version number.
The plugable.Registrar class has changed a bit. I decided to remove
the 'override' keyword argument. It wasn't used anywhere. Overriding
is now automatic based on the plugin class VERSION. Higher version
overrides lower. This way, we can have several versions of the same
plugin living in IPA directory (not in API!) at the same time. It
allows higher versions to easily build on top (extend) older ones.
So to override a plugin you need to have a higher version? What if you
want two separate plugins to extend a plugin, there can be only one? For
example, you have one extension that adds some Samba attributes to a
user and another that adds some Solaris-specific attributes. Not
everyone would want both of these but some might, I think this would
throw a DuplicateError.
Overriding only applies to plugins with exactly the same name. If users
want to have two different plugins available, they can't have the same
name anyway. If they want two plugins in the tree, but only one active
at the same time - then I would suggest using the SkipPluginModule
exception based on configuration as we do with cert plugins.
rob
Pavel
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
