[Zope3-dev] Re: yagni on overrides?

[Martijn Faassen]

Martin Aspeli wrote:
> Leonardo Rochael wrote:
[snip]
>> So, perhaps, we don't need powerful zcml overrides, just cooperative 
>> package
>> maintainers (of which we have plenty in this community).
> 
> That assumes that (a) there are meaningful "sets" of configuration 
> settings and (b) that where people want to override something, it's 
> likely others will need the same overrides.
> 
> I've seen two use cases for overrides.zcml:
> 
>  - Zope 2 code needing to override Zope 3 adapters to do some Zope 
> 2-specific stuff.
> 
>  - Custom code that (i.e. for a specific project) that needs to change 
> the behaviour of some standard component.
> 
> In the two cases above, however, I'm not sure the assumptions hold.

I think they might hold for the Zope 2/Zope 3 scenario. The package 
author would supply a configuration set which configures everything, 
including adapters. The package author would also supply a configuration 
set which *doesn't* configure the adapters. This set is of course reused 
by the former, which simply adds the adapters. Zope 2 code could then 
use the the second set which doesn't register the adapters in the first 
place.

Your second scenario is a bit too abstract to say much about it. In some 
cases if you can get away with a single override, overrides might be 
simpler and relatively easy to maintain. If you have to override a lot, 
configuration sets seem like a better approach.

The great benefit of going for configuration sets is that they actually 
record common override requirements in code instead of having to 
reestablish them each time.

> Having 'configuration sets', if I understand you correctly, would mean 
> keeping two sets in sync even if they only deviate slightly. That'd be 
> cumbersome and risk dependency upgrades breaking things. Thus, it only 
> makes sense if there is a maintainer to look after it all. But even then 
> it would be cumbersome.

You say maintaining configuration sets is *risky* as you might break 
things in upgrades? Cumbersome, yes, I can see that, as people would 
have multiple ZCML files to worry about instead of one. That said, 
presumably you'd have bigger configuration sets reuse bits of the former 
- they shouldn't be copies, which should at least reduce the 
cumbersomeness somewhat.

But risky? I think the maintenance risk overall is reduced. An override 
can easily break if something changes slightly in the overridden 
package. If a set if maintained and there's a public configuration 
contract a package fulfills, maintenance risk should be less.

> You could have some kind of inheritance mechanism, of course. My set 
> extends your one. 

Do I misunderstand you here, or are you referring to the ZCML include 
directive?

> That's not very different from an overrides.zcml, 
> though. I have two "sets of configurations by having two overrides.zcml 
> files and making sure only one is in use at any one time. :)

I think the difference is that some configuration knowledge is 
maintained in the original package, instead of in each place that might 
need an overrides.zcml. The difference is also that it becomes suddenly 
possible to do what people want to accomplish with disabling bits of 
ZCML. Instead of an override disabling another ZCML directive, that ZCML 
directive is not included in the first place.

> When we *predict* the need for things to be overridden, we tend to make 
> things overrideable e.g. with sensible interface modeling to allow a 
> "more specific interface" override for an adapter or view, say. It's the 
> unpredictable cases where overrides.zcml provides a useful safety valve.

I agree that a safety valve needs to remain. I also think that it would 
be quite worthwhile to investigate ways to avoid the need for a safety 
valve in so many cases. Overriding carry a significant maintenance risk: 
you are overriding the configuration contract provided by another 
package. You need to know details about how the other package is 
configured to do it right. It can easily lead to an override breaking if 
a package's configuration changes. It can also easily lead to an 
disabling override not disabling enough, if you use an updated version 
of the package. What for instance if I disable all browser registrations 
in a package I depend on, then upgrade this dependency, and suddenly it 
includes a new browser view?

Anyway, again, I do agree that this might all be somewhat cumbersome to 
maintain. That would be less the case for Grok, as Grok would use tags 
to identify configuration sets. tags are relatively easy to add - a line 
of code per component, in some cases only a line of code per module. No 
need to reorganize separate configuration files, which is a fairly rigid 
way to define configuration sets anyway. If we make those tags be 
interfaces, we suddenly have quite a bit of power in defining 
configuration sets, and in selecting what configuration profile we want 
when using a package's configuration. Lots of details to be worked out 
first, though.

Regards,

Martijn