I just wanted to point out where we ended up wrt reusing zope.configuration in Pyramid.
Pyramid uses zope.configuration internally to provide 2-phase configuration and conflict detection; not just via ZCML but also via imperative Python code. It uses the same "included configuration is overridden by more local configuration" automated conflict detection strategy as used by Zope. I did not emulate "includeOverrides" directly for imperative usage. Instead, Pyramid exposes a "commit" method on it's "configurator" which allows folks to get slightly more control over conflict behavior. Details are here: http://docs.pylonsproject.org/projects/pyramid/1.0/narr/advconfig.html On Tue, 2010-12-07 at 15:32 -0500, Chris McDonough wrote: > On Tue, 2010-12-07 at 14:27 -0500, Chris McDonough wrote: > > > > > [13:48] <mcdonc> override is exactly the wrong phrase to use in the name > > > > of this directive > > > > [13:51] <mcdonc> what it boils down to is that you never, ever really > > > > want to use includeOverrides except in your rootmost zcml file > > > > [13:51] <mcdonc> and probably not even there > > > > [13:51] <mcdonc> because you can get the same effect by typing the > > > > directives there by hand > > > > > > Why would you want to type the directives by hand? > > > > I *think* I'm of the opinion that libraries (or even "reusable > > applications") probably shouldn't need to use includeOverrides. You > > might disagree. I'd actually like to hear your take on that, because > > I'm only about 90% confident about that. ;-) I realize that not every > > application knows whether it's going to be reused or not, but, even so, > > it's always an option to cutnpaste the topmost ZCML from that > > application into a new file and disuse the old one. > > > > But if you take for granted the idea that libraries shouldn't use > > "includeOverrides", the place that it is actually potentially useful is > > in the "deployment" ZCML file (the topmost ZCML file that includes other > > ZCML from libraries and other application packages). But in this > > scenario, I already "own" the topmost ZCML file, and since it's > > deployment-specific, there's no sense in breaking out the included stuff > > into a separate file, because no one else will ever reuse it. It's all > > deployment-specific policy. > > So, arguing with myself about that: > > [14:31] <mcdonc> so i can see exactly one use case for includeOverrides > so far > [14:31] <mcdonc> that's that you have an existing application which > doesnt have its zcml nicely factored > [14:31] <mcdonc> and you're afraid (for whatever reason) to just > cutpaste it into a new app > [14:31] <mcdonc> and you want to create a new package > [14:32] <mcdonc> that includes the other application's zcml then > override bits of it > [14:32] <mcdonc> you could do that by doing > [14:32] <mcdonc> <include package="oldapp"/> > [14:32] <mcdonc> <view ../> > [14:32] <mcdonc> <view ..> > [14:32] <mcdonc> or you could do > [14:32] <mcdonc> <include package="oldapp"/> > [14:33] <mcdonc> <includeOverrides package="newapp.views" > filename="configure.zcml"/> > [14:33] <mcdonc> either would have exactly the same effect > > So yes, I see what you were getting at in your last mail. > > But I think we might be wise to draw some lines around this > reuse-of-an-application pattern, at least conventionally. > > My take on application reuse is this: as soon as you've assumed control > of top-level configuration via a "newapp" overrides package, you've more > or less chosen to use "oldapp" as a library rather than as > just-an-application (NB: oldapp and newapp are names I mention above in > the example of includeOverride, representing an application that wants > to be reused as "oldapp" and a package created by an overriding user as > "newapp"). > > This sort of usage is a bit weird, because usually you depend on a > plain-old-Python library to have a relatively stable API. But in the > application-reuse example, often the original "oldapp" author has > provided no such stability assurances with respect to how he uses ZCML. > In such a case, you're always going to be depending on implementation > details. > > When you punt to reusing oldapp's toplevel ZCML, it's because you don't > want to track changes to oldapp, but you still want to get the benefit > of being able to override some of its policy in newapp. I think this is > pretty much impossible in general. Although your newapp overrides *may* > continue to work across oldapp updates, if oldapp provided no promise of > stability, you'll still need to track its changes. > > It would be much better if the oldapp author provided instructions about > how to best reuse his application as a library. Those instructions > probably wouldn't instruct customizers to reuse his top-level "example" > ZCML configuration, but might imply reusing some other ZCML files that > include configuration unlikely to need to be overridden. Or he might > ship part of "oldapp" as a "true" library that has a bit of ZCML in it > for reuse by integrators, but distribute another package that represents > a deployable configuration of "oldapp" in a separate package. Or > something. > > I dunno, hard topic. > > - C > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) > _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )