Petr Viktorin wrote:
On 07/30/2013 05:16 PM, Nathaniel McCallum wrote:
From 371e080fb6a86da6f0ec574c8cbc0d8d06c18c99 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum<npmccal...@redhat.com>
Date: Tue, 30 Jul 2013 11:13:55 -0400
Subject: [PATCH] Return klass in api.register()
This permits the use of api.register as a decorator.
Thanks for the patch.
Was there any discussion/reason for this? Can you file a ticket?
I'm not opposed, I agree this would allow less typing for plugin authors.
I also think the plugin registration API needs a larger redesign, though
I haven't shared my thoughts on it lately as there are more pressing
things to do. I'll correct that now that there's (sort of) a thread on
the topic :)
Basically, my gripe is that plugin registration only works on the one
global API object, ipalib.api. If you create a different API object, you
can't register plugins on it. Different API object would be useful for
testing, or for running IPA commands on another master (there's an ugly
hack in ipa-replica-install that does that).
A rough sketch of what I had in mind would be:
plugin.py:
# the "register" decorator will collect registered items;
# it must be named "register" so the loading routine finds it
register = plugable.Registry()
@register
class obj_mod(LDAPUpdate):
....
plugable.py:
class Registry:
def __call__(self, item):
self.items.append(item)
class API:
def load_plugin_package(self, package_name):
plugin = __import__(package_name).register
for item in register.items:
self.register(item)
Related ticket for this: https://fedorahosted.org/freeipa/ticket/3090
Maybe if we're giving an incentive for plugin authors to rewrite
plugins, we should give them an API that's at least compatible with the
above goals, so they won't have to rewrite again some time later.
IIRC Jason (the original framework author) did that on purpose so you
could just api anywhere and get the registered API. It was a limitation
to make certain other things easier.
This was also back before the deferred initialization work where
creating an api was very expensive, so maybe its less of an issue.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
