Python plugins, third round

Martin Pool mbp at sourcefrog.net
Thu Jun 16 02:40:45 BST 2005


On 15 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Lalo Martins wrote:
> > So we both worry that this mad plugin loading may slow down bzr too
> > much.  He wants to limit that by loading them on-demand, which would
> > require a very strict naming convention or something like that.  I was
> > more prone to simplifying the plugins so that they could load fast.
> 
> Actually, I'm not sure 'very strict naming convention' is a good
> summary.  One of the alternatives I suggested was for plugins to declare
> which modules they affected.
> 
> As for making plugins load fast, I'm not sure that's possible.  Plugins
> must import any bzr modules they affect, so if you unconditionally
> import a plugin that affects bzrlib.remote_branch (a popular example),
> then you are unconditionally importing bzrlib.remote_branch.  And such a
> module would probably also want to import bzrlib.branch, in order to
> override bzrlib.branch.find_branch.

Bear in mind that Python imports are processed when the import
statement is executed, not (as for Java) when the module is loaded.
So if you import something inside a function or method, it will only
be pulled in when that method runs.

The main place this is hard to do is that you typically need to import
classes at the top level if you want to subclass them.  (I can imagine
contortions to avoid that but it's not good.)

Also, as Fredrik reminded us, an import statement that names a module
that has already been imported anywhere in the interpreter[*] will be
very cheap; just a namespace lookup I suspect.

So on the whole I wouldn't worry about this right now.

> I don't understand this argument.  How would plugins get in the user's
> BZR_PLUGIN_PATH if the user didn't put them there?  If there's a config
> file, I'd hope there's a command to add an entry for the plugin, and
> another to remove it.  But what is the advantage of requiring an extra
> command to install or remove a plugin?

I think we should also make this default to ~/.bzr/plugins (and
perhaps also something system-wide), and allow for it to be extended.
All the modules there can be imported at startup.  If they want to
register any commands, they should do so by e.g. calling a
register_command() function; there's no magic about the names.  That
allows for plugins that do something other than register commands.

As a general principle I wanted to have most options have the same
syntax and similar meaning across commands.  I think svn got this
right and cvs notably wrong.  But obviously some plugins might want to
use options that aren't standard.  Perhaps the Command.takes_options
field should be a list of either standard option names, or tuples
describing new options.

-- 
Martin




More information about the bazaar mailing list