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:

    # the "register" decorator will collect registered items;
    # it must be named "register" so the loading routine finds it
    register = plugable.Registry()

    class obj_mod(LDAPUpdate):

    class Registry:
        def __call__(self, item):

    class API:
        def load_plugin_package(self, package_name):
            plugin = __import__(package_name).register
            for item in register.items:

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.


Freeipa-devel mailing list

Reply via email to