Re: [Zope-dev] my take on ZCML's includeOverrides
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] override is exactly the wrong phrase to use in the name > > > > of this directive > > > > [13:51] what it boils down to is that you never, ever really > > > > want to use includeOverrides except in your rootmost zcml file > > > > [13:51] and probably not even there > > > > [13:51] 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] so i can see exactly one use case for includeOverrides > so far > [14:31] that's that you have an existing application which > doesnt have its zcml nicely factored > [14:31] and you're afraid (for whatever reason) to just > cutpaste it into a new app > [14:31] and you want to create a new package > [14:32] that includes the other application's zcml then > override bits of it > [14:32] you could do that by doing > [14:32] > [14:32] > [14:32] > [14:32] or you could do > [14:32] > [14:33] filename="configure.zcml"/> > [14:33] 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. > > -
Re: [Zope-dev] my take on ZCML's includeOverrides
On Tue, 2010-12-07 at 14:27 -0500, Chris McDonough wrote: > > > [13:48] override is exactly the wrong phrase to use in the name > > > of this directive > > > [13:51] what it boils down to is that you never, ever really > > > want to use includeOverrides except in your rootmost zcml file > > > [13:51] and probably not even there > > > [13:51] 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] so i can see exactly one use case for includeOverrides so far [14:31] that's that you have an existing application which doesnt have its zcml nicely factored [14:31] and you're afraid (for whatever reason) to just cutpaste it into a new app [14:31] and you want to create a new package [14:32] that includes the other application's zcml then override bits of it [14:32] you could do that by doing [14:32] [14:32] [14:32] [14:32] or you could do [14:32] [14:33] [14:33] 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 )
Re: [Zope-dev] my take on ZCML's includeOverrides
On Tue, Dec 7, 2010 at 2:27 PM, Chris McDonough wrote: > On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: >> On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough wrote: >> > Independent of my previous call for discussion about ZCML conflict >> > resolution, I'm cutting and pasting my side of a discussion about the >> > ZCML "includeOverrides" directive from an IRC chat, because it may come >> > in useful for folks grappling with its behavior. There's not really any >> > human-consumable docs about it. >> > >> > If I've made any mistakes, please let me know. >> > >> > [13:42] so ftr, i've found that ZCML's includeOverrides and >> > include to do (at least on one vector) exactly the opposite of what you >> > might expect them to do >> > [13:42] "includeOverrides" is a poor name >> > [13:42] what it does is to emulate the behavior of inlining >> > stuff into the file you use it from >> > [13:43] when you use includeOverrides it's as if you typed all >> > the directives in the included file into the file you're including from >> > [13:43] otoh, "include" doesnt behave like this >> > [13:44] you can actually define the same directive in three >> > files >> > [13:44] configure.zcml, one.zcml, and two.zcml >> > [13:44] and if you use "include" from configure.zcml of one and >> > two >> > [13:44] there will be no conflict >> > [13:45] this is because non-conflicting "rootmost" directives >> > win >> > [13:45] otoh, if you use includeOverrides of one and two from >> > configure.zcml >> > [13:45] all three will conflict >> > [13:45] because its as if you typed them all in configure.zcml >> > by hand >> > [13:45] and that means there are three conflicting rootmost >> > directives >> > [13:46] if you mentally substitute "inline" for >> > "includeOverrides" it makes a little more sense >> >> Maybe. It described the mechanism better, but includeOverrides conveys the >> intent. > > Sorry, not a criticism, just a personal observation. No problem. Your observation is valid. > I assume I'm not wrong about the behavior I describe above? I don't think so. >> > [13:48] override is exactly the wrong phrase to use in the name >> > of this directive >> > [13:51] what it boils down to is that you never, ever really >> > want to use includeOverrides except in your rootmost zcml file >> > [13:51] and probably not even there >> > [13:51] 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. ;-) By now you've probably seen my other post where I said I think we've taken comparability too far. :) I should have noted there that I was talking about "configrability" in terms of selective overriding. If something is going to be configurable, by which I mean overridable, then I think includeOverrides or something like it is pretty valuable. > I realize that not every > application knows whether it's going to be reused or not, Not only that, YAGNI says it should be written from the start as if it isn't, until it is. :) or more importantly, it shouldn't be written to have it's parts overridden until a compelling reason has been found to do so. > 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. Yeah, just like you can reuse Python code by copying it. It's usually better to reuse by reference if possible. > But if you take for granted the idea that libraries shouldn't use > "includeOverrides", Unless the library is built on some other library. Even then, include may be a better option, but there is still overriding going on. > 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). In practice, I haven't found this to be a single file, but that's probably beside the point. > 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. This is like saying that a main program that uses libraries shouldn't be broken into subprograms. Jim -- Jim Fulton ___ 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 )
Re: [Zope-dev] my take on ZCML's includeOverrides
On 12/07/2010 12:27 PM, Chris McDonough wrote: > I *think* I'm of the opinion that libraries (or even "reusable > applications") probably shouldn't need to use includeOverrides. +1, I would be very suspicious of any library that uses includeOverrides. Any use of it ought to be highly visible to developers. Shane ___ 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 )
Re: [Zope-dev] my take on ZCML's includeOverrides
On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: > On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough wrote: > > Independent of my previous call for discussion about ZCML conflict > > resolution, I'm cutting and pasting my side of a discussion about the > > ZCML "includeOverrides" directive from an IRC chat, because it may come > > in useful for folks grappling with its behavior. There's not really any > > human-consumable docs about it. > > > > If I've made any mistakes, please let me know. > > > > [13:42] so ftr, i've found that ZCML's includeOverrides and > > include to do (at least on one vector) exactly the opposite of what you > > might expect them to do > > [13:42] "includeOverrides" is a poor name > > [13:42] what it does is to emulate the behavior of inlining > > stuff into the file you use it from > > [13:43] when you use includeOverrides it's as if you typed all > > the directives in the included file into the file you're including from > > [13:43] otoh, "include" doesnt behave like this > > [13:44] you can actually define the same directive in three > > files > > [13:44] configure.zcml, one.zcml, and two.zcml > > [13:44] and if you use "include" from configure.zcml of one and > > two > > [13:44] there will be no conflict > > [13:45] this is because non-conflicting "rootmost" directives > > win > > [13:45] otoh, if you use includeOverrides of one and two from > > configure.zcml > > [13:45] all three will conflict > > [13:45] because its as if you typed them all in configure.zcml > > by hand > > [13:45] and that means there are three conflicting rootmost > > directives > > [13:46] if you mentally substitute "inline" for > > "includeOverrides" it makes a little more sense > > Maybe. It described the mechanism better, but includeOverrides conveys the > intent. Sorry, not a criticism, just a personal observation. I assume I'm not wrong about the behavior I describe above? > > [13:48] override is exactly the wrong phrase to use in the name > > of this directive > > [13:51] what it boils down to is that you never, ever really > > want to use includeOverrides except in your rootmost zcml file > > [13:51] and probably not even there > > [13:51] 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. > I've used includeOverrides in cases where: > > 1. I want to use 2 high-level components, one of which > customizes the other, or in which > > 2. I wanted to organize overrides in various ways where I > don't want to put everything in a root (or high-level file). > > Of course, you can sometimes get the same effect in other ways. > For example, if one high-level component overrides another, then > the overriding component can just include the overridden one. > > Jim > ___ 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 )
Re: [Zope-dev] my take on ZCML's includeOverrides
On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough wrote: > Independent of my previous call for discussion about ZCML conflict > resolution, I'm cutting and pasting my side of a discussion about the > ZCML "includeOverrides" directive from an IRC chat, because it may come > in useful for folks grappling with its behavior. There's not really any > human-consumable docs about it. > > If I've made any mistakes, please let me know. > > [13:42] so ftr, i've found that ZCML's includeOverrides and > include to do (at least on one vector) exactly the opposite of what you > might expect them to do > [13:42] "includeOverrides" is a poor name > [13:42] what it does is to emulate the behavior of inlining > stuff into the file you use it from > [13:43] when you use includeOverrides it's as if you typed all > the directives in the included file into the file you're including from > [13:43] otoh, "include" doesnt behave like this > [13:44] you can actually define the same directive in three > files > [13:44] configure.zcml, one.zcml, and two.zcml > [13:44] and if you use "include" from configure.zcml of one and > two > [13:44] there will be no conflict > [13:45] this is because non-conflicting "rootmost" directives > win > [13:45] otoh, if you use includeOverrides of one and two from > configure.zcml > [13:45] all three will conflict > [13:45] because its as if you typed them all in configure.zcml > by hand > [13:45] and that means there are three conflicting rootmost > directives > [13:46] if you mentally substitute "inline" for > "includeOverrides" it makes a little more sense Maybe. It described the mechanism better, but includeOverrides conveys the intent. > [13:48] override is exactly the wrong phrase to use in the name > of this directive > [13:51] what it boils down to is that you never, ever really > want to use includeOverrides except in your rootmost zcml file > [13:51] and probably not even there > [13:51] 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've used includeOverrides in cases where: 1. I want to use 2 high-level components, one of which customizes the other, or in which 2. I wanted to organize overrides in various ways where I don't want to put everything in a root (or high-level file). Of course, you can sometimes get the same effect in other ways. For example, if one high-level component overrides another, then the overriding component can just include the overridden one. Jim -- Jim Fulton ___ 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 )
