RFC: centralise registries

[Martin Pool]

2009/4/14 Robert Collins <robertc at robertcollins.net>:
> On Tue, 2009-04-14 at 15:45 +1000, Ian Clatworthy wrote:
>> Robert Collins wrote:
>>
>> > I don't think potential extraction of code is a good reason to keep our
>> > instances and our support classes separate; putting a bunch of instances
>> > in registry.py doesn't make it harder to pull out the class definition
>> > to a new project.
>>
>> It's a layering issue: lower layers shouldn't know about higher layers
>> any more than they need to.
>
> Sure, if we were muddying layers it would be a problem. I don't think
> that would happen.
>
> Do you have alternate suggestions to fix the problem?

A few:

Call a method on plugins to tell them you're about to start running
tests, giving them a chance to register.  Or perhaps rather than
having a special method for this, there should be a hook saying
"selftest is about to begin".

Arguably loading bzrlib.tests should be made much faster by splitting
out the various bits aggregated into that module.  You ought to be
able to think about testing without needing to actually load all the
code needed to run the tests.

Finally, this situation is a bit like that of hooks, where we've ended
up with a registry pointing to all the hooks present in different
places.  So it might perhaps be reasonable to have at least a registry
of registries within registry.py.  But, as I think Ian means, this is
conflating "bzr defines a Registry class" with "bzr has some
registries", and ideally they would be separate.  In practice given
Python's module system and performance it's probably not worth
worrying about too much until the point where we split that class into
a separate library.

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