[Zope-dev] zope-tests - OK: 40
This is the summary for test reports received on the zope-tests list between 2012-04-10 00:00:00 UTC and 2012-04-11 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- ___ 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] Adding broken/missing support to zope.interface?
On Wed, Apr 11, 2012 at 09:30:36AM -0700, Ross Patterson wrote: > Hanno Schlichting writes: > > > On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver wrote: > >> Persistent component registries are not a good enough reason to add such > >> coupling (I'd be in favor of splitting support for persistent registries > >> out of zope.component, too, while we're at it). > >> > >> Let's put the "broken" support into code which depends on > >> zope.interface, zope.component, and the ZODB, and invert the dependency > >> by having the new code install something into the base code which > >> provides the desired support: the only change to zope.interface should > >> be documenting the insertion point, and testing that it does the right > >> thing when a dummy is plugged into it. > > > > I looked at the possible contenders for that dependency description. > > The ZODB depends on zope.interface itself, though not on > > zope.component. > > > > zope.container is the one that has the most minimal dependencies, > > while still relying on zope.component and the ZODB. > > > > zope.site depends on zope.container, but given its scope sounds like > > the better place to me. I vaguely remember us discussing to move > > persistent registries into zope.site at some point. Since we moved > > zope.site.hooks into zope.component, zope.site doesn't have much else > > to do anymore. > > > > Apart from those two, there's a whole lot more that have far more > > dependencies or are unrelated in scope, like zope.annotation or > > zope.catalog. > > This problem isn't so much ZODB specific as it is specific to pickling. > The problem I don't know how to solve without modifying zope.interface > is that the on pickle end of things, the only hook I'm aware of is on > the unpickling side, namely overriding `find_global` as ZODB does. > But there's no way for `find_global` to know that the given global > should be an interface just from the module and name which is what > the pickle contains. We need to hook into the process at the time the > object is pickled. As far as I can see the only way to do that is > through the object's __reduce__ method. > > As such, the only options I see are to add something conditional to > `zope.interface.InterfaceClass.__reduce__` or to make > `zope.interface.InterfaceClass.__reduce__` hookable in some way. Would > the latter address the concerns people are raising here? Tres was suggesting something like that. It would address my concerns. > If so, what's > the right way to approach implement that? I think you need someone intimate with the ZODB to suggest that. One way might be something like the adapter_hooks already present in interface.py. That would at least be consistent, but there are probably many good reasons to not do it that way. That code could look something like: reduce_hooks = [] class InterfaceClass: def __reduce__(self): for hook in reduce_hooks: result = hook(self) if result is not None: return result return self.__name__ > Just monkey patching from > ZODB to zope.interface? Indeed, that is also another option. > > Ross > > ___ > 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 ) -- Brian Sutherland ___ 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] Adding broken/missing support to zope.interface?
Hanno Schlichting writes: > On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver wrote: >> Persistent component registries are not a good enough reason to add such >> coupling (I'd be in favor of splitting support for persistent registries >> out of zope.component, too, while we're at it). >> >> Let's put the "broken" support into code which depends on >> zope.interface, zope.component, and the ZODB, and invert the dependency >> by having the new code install something into the base code which >> provides the desired support: the only change to zope.interface should >> be documenting the insertion point, and testing that it does the right >> thing when a dummy is plugged into it. > > I looked at the possible contenders for that dependency description. > The ZODB depends on zope.interface itself, though not on > zope.component. > > zope.container is the one that has the most minimal dependencies, > while still relying on zope.component and the ZODB. > > zope.site depends on zope.container, but given its scope sounds like > the better place to me. I vaguely remember us discussing to move > persistent registries into zope.site at some point. Since we moved > zope.site.hooks into zope.component, zope.site doesn't have much else > to do anymore. > > Apart from those two, there's a whole lot more that have far more > dependencies or are unrelated in scope, like zope.annotation or > zope.catalog. This problem isn't so much ZODB specific as it is specific to pickling. The problem I don't know how to solve without modifying zope.interface is that the on pickle end of things, the only hook I'm aware of is on the unpickling side, namely overriding `find_global` as ZODB does. But there's no way for `find_global` to know that the given global should be an interface just from the module and name which is what the pickle contains. We need to hook into the process at the time the object is pickled. As far as I can see the only way to do that is through the object's __reduce__ method. As such, the only options I see are to add something conditional to `zope.interface.InterfaceClass.__reduce__` or to make `zope.interface.InterfaceClass.__reduce__` hookable in some way. Would the latter address the concerns people are raising here? If so, what's the right way to approach implement that? Just monkey patching from ZODB to zope.interface? Ross ___ 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] Sanity Check on zope.sessions and Zope 2.12.x
On Wed, Apr 11, 2012 at 1:13 PM, Jeff Rush wrote: > I'm chasing a problem when trying to use zope.sessions with Zope 2.12.x, and > I'm beginning to think that they are an incompatible mix of Zope2 and Zope3 > technologies. > > Can anyone confirm either way, so I know whether I'm wasting my time. Sounds likely. I haven't heard of anyone trying to use zope.session in Zope 2. Does zope.session do something very different from the Zope 2 session manager? You might also want to look at http://pypi.python.org/pypi/collective.beaker for seamlessly integrating Beaker into Zope 2 - with all the advantages of Beaker and different backends. Hanno ___ 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] Sanity Check on zope.sessions and Zope 2.12.x
I'm chasing a problem when trying to use zope.sessions with Zope 2.12.x, and I'm beginning to think that they are an incompatible mix of Zope2 and Zope3 technologies. Can anyone confirm either way, so I know whether I'm wasting my time. What is happening is when I adapt the request I receive to IClientId, the CookieClientIdManager within zope.sessions code (logically) wants to invoke request.response.getCookie(). However the response object my view is receiving is a ZServerHTTPResponse, which lacks such a method. Considering that Zope 2.12.x runs ZServer, it makes sense I'm seeing ZServerHTTPRequest/ZServerHTTPResponse objects, but that means the ClientIdManager inside zope.session is just not compatible with ZServer. Am I missing something? Is there some magic someplace that fixes up the incompatibility in some way I'm missing? I'm guessing my only solution is to re-implement a ClientIdManager utility that restricts itself to the API provided by ZServerHTTPRequest/ZServerHTTPResponse. -Jeff ___ 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 )
