#404 closed enhancement (wontfix)

tahoe plugins: facilitate extensions/applications written in Python — at Version 4

Reported by: zooko Owned by: somebody
Priority: major Milestone: undecided
Component: packaging Version: 1.0.0
Keywords: extensibility Cc:
Launchpad Bug:

Description (last modified by exarkun)

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.

  1. 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. :-)

  1. 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.

Change History (4)

comment:1 Changed at 2008-06-01T20:49:05Z by warner

  • Milestone changed from eventually to undecided

comment:2 Changed at 2009-05-18T19:00:37Z by warner

  • Summary changed from facilitate extensions/applications written in Python to tahoe plugins: facilitate extensions/applications written in Python

comment:3 Changed at 2010-01-15T20:23:04Z by davidsarah

  • Keywords extensibility added

comment:4 Changed at 2020-01-18T00:01:30Z by exarkun

  • Description modified (diff)
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.