Marius Gedminas wrote: [snip]
So I'm -99 for magical side effects of import statements, but thankfully the community opinion is already against them.
Yeah, I was a bit too cavalier in earlier discussions about such a solution. Tres suggested having a proper plugin API for this and a registration function, and I agree. This should be called early in the startup sequence but not during import time.
I'm -0 for having an implementation that seems to be working, but isn't (utility lookup when no utilities can possibly be defined? very useful, that), unless you invoke some magical incantation.
It's only -0 rather than something stronger because the same sort of situation already exists with Interface.__call__ hook, and it doesn't cause any problems in practice (probably because everybody calls placelessSetUp() at the start of their test setUp).
I see this as a bootstrapping issue as we're fiddling with the component architecture itself. Normally when I want to provide a plugin API for a library I'd look into using adapters or utilities. The library would look these up, and external systems have to provide them. If they don't, it won't work (ComponentLookupError) or alternatively the library falls back on default behavior. Such a design pattern I dare say is fairly accepted within the user community of the ZCA. :) But since we are bootstrapping the component architecture itself, we have to come up with an alternative implementation. We instead offer a registration API in zope.interface and we have zope.component register the appropriate plugin. We then modify the startup procedure to tell zope.component to register itself with zope.interface, and we modify the testing infrastructure provided by zope.component to do the same thing. As you say something very similar is going on with the traditional adapter hook already. Regards, Martijn