import tariffs

[Martin Pool]

On 11 February 2010 04:50, John Arbash Meinel <john at arbash-meinel.com> wrote:

> We also have to consider plugins, etc. I think getting the commands
> setup refactored a bit would be good, and push us in the right direction.

You're right, plugins are a bit of an interesting case.  I think I
discussed them a bit in the document.

If you run this test with plugins installed, it may fail when in would
not fail with bzr alone.  (Many tests are like this but this one will
be particularly sensitive.)

I think this is actually a feature, because if having a plugin
installed makes bzr to unnecessarily slow to start that is a bug in
either the plugin or bzr.  For instance we had plugins that
unconditionally loaded qt or gtk and that's bad.

> But right now, some of the code that gets imported is because of:
>
> 1) Overriding an existing command in a plugin. Probably could be done
> with a lazy registry.
>
> 2) Needing to register a Hook, which requires importing the module that
> has the HookPoint. One option would be to move to a 'all HookPoints are
> defined in module hookpoint.py'. At least, we ran into that for the
> per-file merge hooks. We now always have to load 'merge.py' which is a
> fairly involved module, and isn't needed for a lot of commands.

I'm hoping now that we have the import tariff thing in, we can fix
some of these and see the amount of code loaded go down and stay down.

-- 
Martin <http://launchpad.net/~mbp/>