On Sun, Mar 20, 2011 at 4:29 PM, Jim Fulton <j...@zope.com> wrote: > I disagree. First, the notion that you'd import at run time is pretty odd, > unless you count start-up in "runtime".
Right, sorry. I'm used to writing add-ons for an application. In this environment my code isn't in charge of the startup process, but will be called sometime in the middle of it. Some of your code might be imported early, some very late. In this sort of unpredictable environment, scanning comes in handy. Once some of your code is called, you can ensure to scan and register all of it. > Second, well, really, I'm not ready to give up on a straightforward > definition of wiring that doesn't rely on module scanning. Sure. I didn't mean to exclude this. Pyramid allows you to do a very explicit configuration without any scanning. If you write an application and have full control over all its parts, this works. Things get complicated, once you reuse libraries which in turn have other library dependencies with configuration actions. Ignore the naming for the moment. You could call these application components, arguing that a library shouldn't have any hard configuration requirements. Currently we have an explicit approach via providing a configure.zcml in each library, which causes all relevant parts to be imported and hooked up. One library can include the ZCML of another library or a subpackage of its own. Either each library provides a similar central place, which imports all its modules with configuration actions, or you use the scanning approach to avoid the explicit mechanism. > Also, If there's an existing mechanism that does what I want and I'm > just ignorant of, I'd be happy to learn about it. If such a thing > exists or can be cobbled together from existing ideas, I'd like to > elevate it either as part of the ZCA or as a best-practice tool that > stands independent of any particular application framework. I think venusian, the venusian actions and the configuration machinery of Pyramid come pretty close to this. Personally I think we could extract these and roll them back into the ZTK. Maybe there's something in Grok that comes close to this. I've just not been able to distinguish the "Grok the web framework" code with its convention over configuration idea from some basic explicit configuration approach. Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )