On Thu, Feb 26, 2009 at 7:07 AM, Martijn Faassen <faas...@startifact.com> wrote: > Hey, > > On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev <nad...@gmail.com> wrote: >> Yep, I know about z3c.autoinclude, but I don't like it, as it makes >> things more implicit and it also > > Yes, automation makes things more implicit. This is *not* an argument > that can be used against any and all automation. An explicit > includeDependencies directive will include the configure.zcml and > meta.zcml of packages that are dependencies of that package. You make > less mistakes this way (and it's very common to make the mistake to > forget inclusion of some ZCML). It's also pretty rare to want to do > otherwise in my experience (and there's always the exclude directive). > > I'd also argue auto-inclusion can actually help guard against > dependency bugs, such as cases where a package tries to include ZCML > it doesn't depend on (and works because some other package makes the > dependency installed).
+1 on Martijn's points (unsurprisingly, as I'm one of his co-authors on autoinclude ;) I'll also add that z3c.autoinclude tries very hard to log its actions in an easily traceable way, and I've been trying to build in more debugging tools as well. >> slows down startup time for >> applications that uses many eggs. > > When claims like that are made, I'd like to see measurements that > demonstrate significant slowdowns during startup. Undoubtedly more > code is excuted than when you write out 'include' directives manually, > but is the slowdown actually measurable? I've heard this claim before and I'd also love to see some measurements. I haven't really had the time to do any myself, and in my experience z3c.autoinclude hasn't slowed things down enough to bother me. But I may have an unusually high tolerance for slow-moving code. :) The slowest code in z3c.autoinclude is well isolated and is tested for many edge cases, and I'm pretty sure there are obvious optimizations that can be made without even rewriting it. So improving the execution speed should be quite easy and safe; it just hasn't been a priority for me, and I'd prefer to get some measurements before trying to tweak it. >> I'd like to see an option for >> packages that are using z3c.autoinclude to make autoincluding >> conditional, so those who doesn't like it or needs more control could >> just turn it off. > > That's asking for a feature that other packages that *don't* use > autoinclude don't support! You lose control as soon as you include a > package's "configure.zcml". There's no difference with > non-auto-inclusion here; [snip] That's true on paper, but in practice z3c.autoinclude's *indirection* does make a difference when you're just trying to debug what's going on. At any rate, the next release of z3c.autoinclude will provide this feature, through environment variables: http://lists.plone.org/pipermail/framework-team/2009-February/002690.html Regards, Ethan _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )