plugin system?

[Jeff Epler]

On Thu, Apr 03, 2003 at 03:33:37PM +1200, Rob Brown-Bayliss wrote:
> 
> Whats with the following exec statment?
> 
[Jeff Epler:]
> > In the code, you would instantiate the class with a helper function:
> >     def get_plugin_factory(name):
> >         # If you have packages (eg monty_python.spam.VikingChorus
> >         # or spam.spam.spam.spam.baked-beans.spam) this won't work
> >         # as written
> >         m, f = name.split(".")
> >         d = {}
> >         exec "import m" in d
> >         return eval(name, d)
> 
> I admit I havn't tried it yet, but what does the exec "import m" in d
> do?

The idea in the (untested) code was that making packages work would be a
simple addition.  You'd make m get name up to the last '.', so that for the
plugin 'pack.mod.plugin' you'd 'import pack.mod' and then get the value of
pack.mod.plugin.  As written, though, only names of the form
'modulename.factoryname' are intended to work.  There's no reason you can't
do this with the __import__ approach too.

In my view, the thing returned should act as a factory (including the
possibility of just being a class), so if you call it more than once you
should get two independent instances of the plugin.

In your code, it looks like 'newcog' names a module, and you can't easily
make a copy of a module.  When you name a factory, it becomes easy to ask
for more than one, to parameterize, etc.

Jeff