RFC: centralise registries

Robert Collins robertc at robertcollins.net
Tue Apr 14 10:30:36 BST 2009


On Tue, 2009-04-14 at 19:08 +1000, Martin Pool wrote:
> 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".

That solves one instance of this issue; there are quite a few registries
now. Calling back to plugins is what I mentioned in one of my other
mails.

Hooks have the same issue as registries actually - you have to load the
hook object you want to register with for callbacks, and like registries
we have them near the code to run [good] but this means we load code we
may not need.

I think actually the root of the issue is that there is no way for a
plugin to say 'I would register with some X but I don't want to trigger
that X'. twisted achieves this by plugin metadata - plugins are a Y, and
this is memoised and then the plugin is called into for Y operations. I
think this is overly constraining.

Perhaps though we can directly solve that issue: Have a hook for imports
- we can insert an import hook (ugh - different 'hook' :P) into the
import system [easy, quite safe] and when e.g. bzrlib.tests has been
imported call any code that has registered an interest in that module.
so
from bzrlib.tests import parallel_registry
parallel_registry.register('ec2', ec2_for_tests)
becomes
def register_ec2():
    from bzrlib.tests import parallel_registry
    parallel_registry.register('ec2', ec2_for_tests)
from bzrlib.lazy_import import lazy_load_hooks
lazy_load_hooks.after_import('bzrlib.tests', register_ec2)

Where after_import is guaranteed to fire immediately if bzrlib.tests is
imported, and otherwise adds ('bzrlib.tests', register_ec2) to a mapping
that the import hook will check and call.

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

Well, what does 'think about testing' mean here :).

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090414/4e5b2978/attachment.pgp 


More information about the bazaar mailing list