Martin Aspeli wrote:
Leonardo Rochael wrote:
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.



Zope3-dev mailing list

Reply via email to