RFC: centralise registries

[Martin Pool]

2009/4/14 Robert Collins <robertc at robertcollins.net>:
> 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.

It seems like this is just shuffling the problem around.  You still
have, essentially, a registry, it's just now called lazy_load_hooks.
We come back to wanting to make sure that it's possible to register
for things without loading much more code, whether that be by directly
making sure the places they currently live are cheap, or putting them
somewhere else.

You don't actually care about knowing when the module is loaded for
its own sake, so I'd be disinclined to add a mechanism that does that.

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

For instance, importing the TestCase base class.

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