[Twisted-Python] Plugin startup and shutdown actions
I would like to port my Application API based services to the twistd plugin interface, to be able to retrieve command line options. In the existing services, I reimplemented t.a.s.MultiService startService() and stopService() to do some actions at startup and shutdown. How can I do this in a plugin ? -- Lup
On Sat, 11 Apr 2009 00:24:37 +0200, luper rouch <luper.rouch@gmail.com> wrote:
I would like to port my Application API based services to the twistd plugin interface, to be able to retrieve command line options.
In the existing services, I reimplemented t.a.s.MultiService startService() and stopService() to do some actions at startup and shutdown.
How can I do this in a plugin ?
The top-level API for plugins is mostly a function that returns an IService provider. So if you have your own version of MultiService, you can just return an instance of that, just like the one you were creating in your .tac file, from a makeService function which is registered as a plugin of the suitable type. Jean-Paul
2009/4/11 Jean-Paul Calderone <exarkun@divmod.com>:
On Sat, 11 Apr 2009 00:24:37 +0200, luper rouch <luper.rouch@gmail.com> wrote:
I would like to port my Application API based services to the twistd plugin interface, to be able to retrieve command line options.
In the existing services, I reimplemented t.a.s.MultiService startService() and stopService() to do some actions at startup and shutdown.
How can I do this in a plugin ?
The top-level API for plugins is mostly a function that returns an IService provider. So if you have your own version of MultiService, you can just return an instance of that, just like the one you were creating in your .tac file, from a makeService function which is registered as a plugin of the suitable type.
Thanks I didn't think it was so simple ! I have a last question, I put my plugins in a 'twisted/plugins' subfolder of my project, and running them from the command line works fine. How can I invoke them in unit tests (I need to be able to start and stop them), since the plugin files are not in a package ?
On Sat, 11 Apr 2009 19:29:28 +0200, luper rouch <luper.rouch@gmail.com> wrote:
2009/4/11 Jean-Paul Calderone <exarkun@divmod.com>:
On Sat, 11 Apr 2009 00:24:37 +0200, luper rouch <luper.rouch@gmail.com> wrote:
I would like to port my Application API based services to the twistd plugin interface, to be able to retrieve command line options.
In the existing services, I reimplemented t.a.s.MultiService startService() and stopService() to do some actions at startup and shutdown.
How can I do this in a plugin ?
The top-level API for plugins is mostly a function that returns an IService provider. So if you have your own version of MultiService, you can just return an instance of that, just like the one you were creating in your .tac file, from a makeService function which is registered as a plugin of the suitable type.
Thanks I didn't think it was so simple !
I have a last question, I put my plugins in a 'twisted/plugins' subfolder of my project, and running them from the command line works fine. How can I invoke them in unit tests (I need to be able to start and stop them), since the plugin files are not in a package ?
They can be imported from "twisted.plugins". For example, if you name your "dropin" file foo_plugins.py, then "from twisted.plugins import foo_plugins" should work and let you test any code that is part of your plugin definitions. Note that you should try to keep the amount of code and dependencies in a dropin file to a minimum, since this must all be loaded and executed whenever a search for any plugin is performed. Jean-Paul
On Saturday 11 April 2009 19:42:31 Jean-Paul Calderone wrote:
They can be imported from "twisted.plugins". For example, if you name your "dropin" file foo_plugins.py, then "from twisted.plugins import foo_plugins" should work and let you test any code that is part of your plugin definitions. Note that you should try to keep the amount of code and dependencies in a dropin file to a minimum, since this must all be loaded and executed whenever a search for any plugin is performed.
Shouldn't twisted and twisted/plugins be non-importable? I thought twisted and twisted/plugins must not have __init__.py files in order for the plugin system to be able to find them (through getPlugins). Or did that behavior change in recent versions? Cheers.
On Sat, 11 Apr 2009 21:54:08 +0200, Esteve Fernandez <esteve@sindominio.net> wrote:
On Saturday 11 April 2009 19:42:31 Jean-Paul Calderone wrote:
They can be imported from "twisted.plugins". For example, if you name your "dropin" file foo_plugins.py, then "from twisted.plugins import foo_plugins" should work and let you test any code that is part of your plugin definitions. Note that you should try to keep the amount of code and dependencies in a dropin file to a minimum, since this must all be loaded and executed whenever a search for any plugin is performed.
Shouldn't twisted and twisted/plugins be non-importable? I thought twisted and twisted/plugins must not have __init__.py files in order for the plugin system to be able to find them (through getPlugins). Or did that behavior change in recent versions?
They must not have __init__.py files, indeed. However, the files in twisted/plugins/ still define sub-modules of the twisted.plugins package due to the code in Twisted's twisted/plugins/__init__.py. Jean-Paul
On 11 Apr, 08:39 pm, exarkun@divmod.com wrote:
On Sat, 11 Apr 2009 21:54:08 +0200, Esteve Fernandez <esteve@sindominio.net> wrote:
Shouldn't twisted and twisted/plugins be non-importable? I thought twisted and twisted/plugins must not have __init__.py files in order for the plugin system to be able to find them (through getPlugins). Or did that behavior change in recent versions?
They must not have __init__.py files, indeed. However, the files in twisted/plugins/ still define sub-modules of the twisted.plugins package due to the code in Twisted's twisted/plugins/__init__.py.
They must not have __init__.py files specifically to avoid *conflicting* with this Twisted's twisted/plugins/__init__.py. Since the idea is that, during installation, your foo_plugin.py will go into the site's twisted/plugins directory, we forbid projects to make twisted/plugins a package because otherwise one package would stomp over the other's __init__.py and break things.
2009/4/11 Esteve Fernandez <esteve@sindominio.net>:
On Saturday 11 April 2009 19:42:31 Jean-Paul Calderone wrote:
They can be imported from "twisted.plugins". For example, if you name your "dropin" file foo_plugins.py, then "from twisted.plugins import foo_plugins" should work and let you test any code that is part of your plugin definitions. Note that you should try to keep the amount of code and dependencies in a dropin file to a minimum, since this must all be loaded and executed whenever a search for any plugin is performed.
Shouldn't twisted and twisted/plugins be non-importable? I thought twisted and twisted/plugins must not have __init__.py files in order for the plugin system to be able to find them (through getPlugins). Or did that behavior change in recent versions?
Cheers.
It's working on 8.2.0 release, I have been able to port all my tests to the plugins API (they even seem less hackish now...) Thanks !
participants (4)
-
Esteve Fernandez -
glyph＠divmod.com -
Jean-Paul Calderone -
luper rouch