On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough <chrism@plope.com> wrote:
I'm trying to decide whether to repurpose the conflict detection in zope.configuration for non-XML configuration.
Cool. ...
Unfortunately, the documentation in the code tends to explains the mechanics of conflict resolution, but not the intent. I'll take a guess though:
- the "rootmost" directive that participates in a conflict is meant to "win".
- if there is more than one "rootmost" directive that participates in a conflict, the conflict cannot be resolved.
Does my summary sound about right?
Yes, but ...
Does anyone have any insight as to why this particular conflict resolution strategy was chosen? I'm really just trying to understand the intent.
The intent was to provide a way of overriding configuration in a way that was unambiguous and understandable. (Of course, it fails in the case of subscribers, but I think that's beside your point. :) Let's take this up a level, to user goals. A user wants to reuse a high-level component (aka package aka "project" in distutils jargon aka "product" in distutils jargon). They want to customize the high-level component without hacking its code. *That* is really the intent. Jim -- Jim Fulton