[Zope-dev] Zope Tests: 94 OK, 4 Failed
Summary of messages to the zope-tests list. Period Mon Dec 6 12:00:00 2010 UTC to Tue Dec 7 12:00:00 2010 UTC. There were 98 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 19 from buildbot at winbot.zope.org, 11 from ccomb at free.fr, 56 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zopetoolkit-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:58:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025802.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Mon Dec 6 14:19:13 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025808.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.7 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Mon Dec 6 14:25:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025810.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Mon Dec 6 14:31:11 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025814.html Tests passed OK --- Subject: OK : Zope Buildbot / zope2.12-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:02:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025770.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:05:16 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025771.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:07:33 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025772.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:09:47 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025773.html Subject: OK : Zope Buildbot / zope2.14-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:12:02 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025774.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:20:58 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025775.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:29:58 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025776.html Subject: OK : Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:39:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025777.html Subject: OK : Zope Buildbot / zopetoolkit-py2.5 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:44:40 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025778.html Subject: OK : Zope Buildbot / zopetoolkit-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:50:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025779.html Subject: OK : Zope Buildbot / zopetoolkit-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:56:23 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025780.html Subject: OK : Zope Buildbot / zope2.14-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 07:59:20 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025781.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 08:01:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025782.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 08:03:50 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025783.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Mon Dec 6 08:06:07 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025784.html Subject: OK : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:19:53 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025785.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:21:29 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025786.html Subject: OK : Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Mon Dec 6 13:23:02 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-December/025787.html Subject: OK : Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 From: jdriessen at
[Zope-dev] Zope 2.13 and zope.publisher = 3.9
Hello, In zope.publisher 3.9.0, the signature of the redirect method of a response changed to include a new trusted option that you *need* to set to True in order to get redirect working in most cases (otherwise it denies the redirect that are not in the domain than your application). That new option annoy me in Zope 2.13, as there is no such option to the redirect method on the Zope 2 response. Now I am working in five.grok which uses grokcore.view. Grokcore.view provides some redirect utilities, and they have to use that trusted option in order to get things working. And they doesn't work in Zope 2 anymore. So I would like a bit of help to fix that problem. I see two possible solutions: - changing the default value of the trusted option in zope.publisher, to be a bit more backward compatible (and call that redirect with trusted=False in zope.[app].authentication where it motivated that change), - add a trusted option to redirect in Zope 2. What do you thing what should be done ? (Yes, I will create a launchpad issue, but I would like to see that issue fixed more or less quickly). Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ 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] ZCML conflict resolution
I'm trying to decide whether to repurpose the conflict detection in zope.configuration for non-XML configuration. zope.configuration has the following resolveConflicts function, which attempts to resolve action discriminator conflicts. def resolveConflicts(actions): Resolve conflicting actions Given an actions list, identify and try to resolve conflicting actions. Actions conflict if they have the same non-null discriminator. Conflicting actions can be resolved if the include path of one of the actions is a prefix of the includepaths of the other conflicting actions and is unequal to the include paths in the other conflicting actions. ... The code in resolveConflicts indeed matches the docstring description. In the test_simple.py test file, a little more light is shed on conflict resolution: Conflicting actions can be resolved if one of the conflicting actions is from a configuration file that directly or indirectly includes the files containing the other conflicting actions. There's also a test in test_xmlconfig.py that goes into details about includeOverrides and conflict detection. (Note that I don't care about includeOverrides here. I think I understand it, after some wrangling with it.) 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? Does anyone have any insight as to why this particular conflict resolution strategy was chosen? I'm really just trying to understand the intent. - 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] my take on ZCML's includeOverrides
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] mcdonc 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] mcdonc includeOverrides is a poor name [13:42] mcdonc what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] mcdonc 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] mcdonc otoh, include doesnt behave like this [13:44] mcdonc you can actually define the same directive in three files [13:44] mcdonc configure.zcml, one.zcml, and two.zcml [13:44] mcdonc and if you use include from configure.zcml of one and two [13:44] mcdonc there will be no conflict [13:45] mcdonc this is because non-conflicting rootmost directives win [13:45] mcdonc otoh, if you use includeOverrides of one and two from configure.zcml [13:45] mcdonc all three will conflict [13:45] mcdonc because its as if you typed them all in configure.zcml by hand [13:45] mcdonc and that means there are three conflicting rootmost directives [13:46] mcdonc if you mentally substitute inline for includeOverrides it makes a little more sense [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 - 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 1:57 PM, Chris McDonough chr...@plope.com 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] mcdonc 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] mcdonc includeOverrides is a poor name [13:42] mcdonc what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] mcdonc 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] mcdonc otoh, include doesnt behave like this [13:44] mcdonc you can actually define the same directive in three files [13:44] mcdonc configure.zcml, one.zcml, and two.zcml [13:44] mcdonc and if you use include from configure.zcml of one and two [13:44] mcdonc there will be no conflict [13:45] mcdonc this is because non-conflicting rootmost directives win [13:45] mcdonc otoh, if you use includeOverrides of one and two from configure.zcml [13:45] mcdonc all three will conflict [13:45] mcdonc because its as if you typed them all in configure.zcml by hand [13:45] mcdonc and that means there are three conflicting rootmost directives [13:46] mcdonc if you mentally substitute inline for includeOverrides it makes a little more sense Maybe. It described the mechanism better, but includeOverrides conveys the intent. shrug [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'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 )
[Zope-dev] We work waaaaay to hard to make everything configurable (Re: ZCML conflict resolution)
On Tue, Dec 7, 2010 at 1:51 PM, Jim Fulton j...@zope.com wrote: On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough chr...@plope.com wrote: ... 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. BTW, we work way to hard to satisfy the second part of this goal. Yeah, somethings do want to be configurable. But we make things far more configurable than they need to be and we've paid a high price in complexity. The answer to this IMO isn't to make configuration easier, better, more automatic, or implicit, or whatever. (Let's just take the spoon out of the glass. :) 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 Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough chr...@plope.com 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] mcdonc 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] mcdonc includeOverrides is a poor name [13:42] mcdonc what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] mcdonc 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] mcdonc otoh, include doesnt behave like this [13:44] mcdonc you can actually define the same directive in three files [13:44] mcdonc configure.zcml, one.zcml, and two.zcml [13:44] mcdonc and if you use include from configure.zcml of one and two [13:44] mcdonc there will be no conflict [13:45] mcdonc this is because non-conflicting rootmost directives win [13:45] mcdonc otoh, if you use includeOverrides of one and two from configure.zcml [13:45] mcdonc all three will conflict [13:45] mcdonc because its as if you typed them all in configure.zcml by hand [13:45] mcdonc and that means there are three conflicting rootmost directives [13:46] mcdonc if you mentally substitute inline for includeOverrides it makes a little more sense Maybe. It described the mechanism better, but includeOverrides conveys the intent. shrug Sorry, not a criticism, just a personal observation. I assume I'm not wrong about the behavior I describe above? [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. 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 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, Dec 7, 2010 at 2:27 PM, Chris McDonough chr...@plope.com wrote: On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough chr...@plope.com 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] mcdonc 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] mcdonc includeOverrides is a poor name [13:42] mcdonc what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] mcdonc 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] mcdonc otoh, include doesnt behave like this [13:44] mcdonc you can actually define the same directive in three files [13:44] mcdonc configure.zcml, one.zcml, and two.zcml [13:44] mcdonc and if you use include from configure.zcml of one and two [13:44] mcdonc there will be no conflict [13:45] mcdonc this is because non-conflicting rootmost directives win [13:45] mcdonc otoh, if you use includeOverrides of one and two from configure.zcml [13:45] mcdonc all three will conflict [13:45] mcdonc because its as if you typed them all in configure.zcml by hand [13:45] mcdonc and that means there are three conflicting rootmost directives [13:46] mcdonc if you mentally substitute inline for includeOverrides it makes a little more sense Maybe. It described the mechanism better, but includeOverrides conveys the intent. shrug 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] 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. ;-) 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 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 )
