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.



Freeipa-devel mailing list

Reply via email to