[tahoe-lafs-trac-stream] [Tahoe-LAFS] #404: tahoe plugins: facilitate extensions/applications written in Python

[Tahoe-LAFS]

#404: tahoe plugins: facilitate extensions/applications written in Python
-----------------------------+---------------------------
     Reporter:  zooko        |      Owner:  somebody
         Type:  enhancement  |     Status:  closed
     Priority:  major        |  Milestone:  undecided
    Component:  packaging    |    Version:  1.0.0
   Resolution:  wontfix      |   Keywords:  extensibility
Launchpad Bug:               |
-----------------------------+---------------------------
Changes (by exarkun):

 * status:  new => closed
 * resolution:   => wontfix


Old description:

> Suppose you want to write an application that uses Tahoe, or suppose you
> want to add an extension to Tahoe.  You can run your code in a separate
> process and use the WAPI, but if your application or extension is written
> in Python it can have better control over Tahoe's behavior, be a bit more
> efficient, and be simpler by making Python method invocations to Tahoe
> instead of HTTP requests.
>
> But how should you get your code loaded into the same Python interpreter
> as the Tahoe code?  The answer is you either use {{{import}}} to load the
> Tahoe code and then you run it (precisely how, I'm not sure -- perhaps by
> calling {{{startService()}}} on it?), or you arrange for the Tahoe app to
> load your code at runtime when it is started by e.g. the command-line
> {{{tahoe start}}}.
>
> The latter case is called a "plugin".  There are three examples of plugin
> systems that we could use:
>
> 1.  The setuptools plugin system, as exemplified by trac:
> http://trac.edgewall.org/wiki/TracPlugins
>
> In this system, you put a ".egg" containing your code into a directory,
> and then you configure in a configuration file whether you want trac to
> load a plugin by that name.
>
> 2.  The twisted plugin system, as documented here:
> http://twistedmatrix.com/projects/core/documentation/howto/plugin.html
>
> I don't know if this is much used, but the way David Reid explained it to
> me it sounded nice and simple.  :-)
>
> 3.  The mercurial extension system, as documented here:
> http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions
>
> You just put the name of your extension into your Mercurial config file,
> and then when it runs it attempts to {{{import ThatName}}}, so you have
> to make sure a module (or directory-with-init.py-file) by that name is on
> your {{{PYTHONPATH}}}.

New description:

 Suppose you want to write an application that uses Tahoe, or suppose you
 want to add an extension to Tahoe.  You can run your code in a separate
 process and use the WAPI, but if your application or extension is written
 in Python it can have better control over Tahoe's behavior, be a bit more
 efficient, and be simpler by making Python method invocations to Tahoe
 instead of HTTP requests.

 But how should you get your code loaded into the same Python interpreter
 as the Tahoe code?  The answer is you either use {{{import}}} to load the
 Tahoe code and then you run it (precisely how, I'm not sure -- perhaps by
 calling {{{startService()}}} on it?), or you arrange for the Tahoe app to
 load your code at runtime when it is started by e.g. the command-line
 {{{tahoe start}}}.

 The latter case is called a "plugin".  There are three examples of plugin
 systems that we could use:

 1.  The setuptools plugin system, as exemplified by trac:
 http://trac.edgewall.org/wiki/TracPlugins

 In this system, you put a ".egg" containing your code into a directory,
 and then you configure in a configuration file whether you want trac to
 load a plugin by that name.

 2.  The twisted plugin system, as documented here:
 http://twistedmatrix.com/projects/core/documentation/howto/plugin.html

 I don't know if this is much used, but the way David Reid explained it to
 me it sounded nice and simple.  :-)

 3.  The mercurial extension system, as documented here:
 http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions

 You just put the name of your extension into your Mercurial config file,
 and then when it runs it attempts to {{{import ThatName}}}, so you have to
 make sure a module (or directory-with-init.py-file) by that name is on
 your {{{PYTHONPATH}}}.

--

Comment:

 So ... yea ... but this ticket is too general.  Plugins *for what*?  To
 have a plugin, you need a plugin interface.  To have a plugin interface,
 you need an extension point.  Tahoe-LAFS has many possible extension
 points.  I implemented one recently to let plugins supply an alternate
 storage protocol.

 We probably need a ticket per desired extension point.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/404#comment:4>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage