[Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.

[Ethan Jucovy]

On Thu, Feb 26, 2009 at 7:07 AM, Martijn Faassen <faassen at startifact.com> wrote:
> Hey,
>
> On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev <nadako at 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