Python plugins, third round

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On 15 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 
>>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.)

The other case where it's hard is when you want to change module values,
e.g.

branch.branch_types['sftp://'] = SftpBranch

# or monkey-patching example
_real_find_branch = branch.find_branch
def find_branch(loc):
    if loc.startswith('sftp://'):
        return SftpBranch(loc)
    else:
        return _real_find_branch(loc)
branch.find_branch = find_branch

So I think most of the time, importing a plugin will mean importing the
section of bzrlib that the plugin affects, too.

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

Oh, sure.  But it could cause you to load remote_branch when you
otherwise wouldn't.

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

Okay.

> I think we should also make this default to ~/.bzr/plugins (and
> perhaps also something system-wide),

Yes, a system-wide path would be very nice.  If we supported packages in
there as well as modules, I'd be a happy camper indeed.

> and allow for it to be extended.

Or set to empty too, I suppose.


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

Sure.  There is a bit of a chicken-and-egg problem.  Consider

bzr commit --something --builtin

If the user specifies --builtin, then we should not import a
non-standard commit.  But we don't know whether --something takes an
argument, so --builtin might be an argument, not an option.

Okay, so it's not all that likely :-)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCsOMx0F+nu1YWqI0RAnieAJ9kcDdyDiN3SyHKVqfK+aixwrwHUQCfS9mh
Y3j7J4KA8jXdxvWrm6+J4y8=
=q7zB
-----END PGP SIGNATURE-----