Hello, * Martin Aspeli <optilude+li...@gmail.com> [2011-03-25 13:58]: > plone.testing (which is Plone non-specific and will shortly be BSD > licensed) allows for stacking of ZCA registries. > [...] > Again, plone.testing is the result of hours and hours of finding weird > problems, so I'd recommend you don't discard the knowledge there. I > think a best case scenario would be for plone.testing.zca to just be a > delegate for something more robust in zope.component.testing.
I wasn't aware plone.testing had something for the ZCA, before I read that in this thread yesterday. I'm glad to hear that, and I certainly don't want to discard anything. But from reading the code and what you wrote, I get the impression that plone.testing does not yet solve the issue completely, precisely because of the two points I brought up and that continue below: > On 25 March 2011 13:17, Jim Fulton <j...@zope.com> wrote: > > On Fri, Mar 25, 2011 at 4:24 AM, Wolfgang Schnerring <w...@gocept.com> > > wrote: > > > we realized that just squeezing in a new registry and bending its > > > bases to the previously active one is not enough for full isolation, > > > since this does not cover *deleting* registrations > > > > Is deleting registrations important? This seems like an odd use case. > > If it's needed, I would suggest starting with a baseline (e.g. stack) > > that doesn't include the component you want to test deleting, then > > adding in setup. I've wanted to specifically nuke registrations sometimes, the pattern being, load the package's configure.zcml in the layer, and then delete something (to demonstrate some error handling behaviour). I agree that this use case is rare, but I'm not sure it is rare enough that we should ignore it. I need to think about this some more, though. > > > 2. zope.component has two entry points, the global site registry and > > > the current registry (getGlobalSiteManager and getSiteManager). > > > The current registry can be anything, or more precisely, you can call > > > getSiteManager.sethook(callable) and provide a callable that returns > > > the current registry. > > > > > > I think to provide test support for zope.component (i. e. generally, > > > at the "library level"), we need to support both entry points. > > > > Why? Why would someone care about anything other than the current > > effective configuration. Because that's the API that zope.component offers, it conceptually deals with *two* registries: the one you get from getSiteManager and the one you get from getGlobalSiteManager. I agree that it is unlikely that client code will *read* registrations using getGlobalSiteManager -- since most everyone uses zope.component.getUtility etc. (which in turn uses getSiteManager). But *writing* is a different matter. Just one example: zope.component.provideUtility etc. uses getGlobalSiteManager, while the ZCML directives use getSiteManager. At least as long as zope.component.provide* uses getGlobalSiteManager instead of getSiteManager, I maintain that test infrastructure needs to 1. wrap the global registry 2. wrap whatever getSiteManager currently returns (Otherwise we might be able get away with not doing (1), but I think we'll always need to do (2).) plone.testing has it the other way around, doing (1) but not (2), as Martin says himself... > > > The global one is not hard, but the getSiteManager one gets > > > nasty really fast, because of course we have to rely on bending > > > getSiteManager to return the current "test registry" > > I don't think you need to do that. plone.testing doesn't, for sure, it > just changes the variable that getSiteManager() looks at. ... and I'm quite sure that's wrong, becasue it doesn't deal with the issue of getSiteManager at the level of zope.component, but at the level of some specific implementations (zope.site and five.localsitemanager, to be precise). When I'm using, say, Pyramid (which also uses getSiteManager.sethook), this won't help me at all. And to do this on the level of zope.component, I'm quite sure we are going to need to override getSiteManager. > > > but anyone could at any time call getSiteManager.sethook to > > > change it! > > > > Seriously? Nobody calls that but deep infrastructure code. > > Agree with Jim. Are you going to stop people monkey patching > getSiteManager() too? ;-) My point is: Ensuring that test setup always and everywhere happens precisely so that the code that calls sethook (for example the setup of zope.site) is called *before* the envisioned test infrastructure code comes along to bend getSiteManager to do its will seems very fragile to me, if it's doable at all. Wolfgang -- Wolfgang Schnerring · w...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development _______________________________________________ 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 )