Bzr's startup time

[Martin Pool]

On 26 Jun 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:

> > I'm still quite fond of the approach I used in Bugs Everywhere, in which
> > each command corresponds to a module with the same name.  In BE, when
> > you run 'be set-root', it finds a file named 'becommands/set_root.py'
> > and imports it.
> > 
> > I believe we could easily integrate that approach with our current
> > structure, except that we would need to change alias handling.  Keeping
> > aliases in the Command object would mean they would not be loaded when
> > we needed them, so we would need to separate the alias list from the
> > Command objects.
> > 
> > Aaron
> 
> Yeah. At this point you need some kind of registry (at least for
> aliases). And we should think how this would work for plugins as well.
> 
> We could just have a list of lazy imports/registrations in commands.py
> or builtins.py.
> 
> I think the registration function could take a list, rather than calling
> it N times for all the different commands, just call it 1 time with a
> big table.
> 
> We can still load the class, and figure out what its arguments are, etc,
> when we are parsing the command line arguments.
> So all it would really mean is instead of looking at globals() and
> searching for things that start with cmd_*, we could put a call to
> 'register_builtin_commands()' at the bottom of builtins.py, and slowly
> migrate commands out of that file into children files. Say in
> bzrlib/commands/foo.py
> Or if we prefer:
> bzrlib/commands/cmd_foo.py
> 
> The only real change is to switch from a 'get these implicitly', to
> calling a registration function. I think the number of new commands has
> settled down, so it is okay to start being more explicit about it.
> (Plugins already have to register their commands).

Yes, that sounds reasonable to me.

This is, incidentally, a classic case where you would like to try
to merge across a split file.  There are some cases where a sufficiently
good merger ought to be able to do it, in this case by anchoring off the
classname.  I can imagine extracting something like patch hunks that
can't be applied, then trying to anchor them by looking at lines that
are unique across the whole tree.  (Or perhaps at lines that are unique
across all files that have split out from that point.)

-- 
Martin