[Zope-dev] zope-tests - FAILED: 10, OK: 31, UNKNOWN: 1
This is the summary for test reports received on the zope-tests list between 2011-08-31 00:00:00 UTC and 2011-09-01 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.4.6 64bit linux Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.5 64bit linux [1]UNKNOWN : winbot / ZODB_dev py_270_win32 ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit [2]ZTK 1.0dev / Python2.4.6 Linux 64bit [3]ZTK 1.0dev / Python2.5.5 Linux 64bit [4]ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux 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_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win64 [5]winbot / zope.pagetemplate_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 [6]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 [7]winbot / ztk_dev py_254_win32 [8]winbot / ztk_dev py_265_win32 [9]winbot / ztk_dev py_265_win64 [10] winbot / ztk_dev py_270_win32 [11] winbot / ztk_dev py_270_win64 Non-OK results -- [1]UNKNOWN UNKNOWN : winbot / ZODB_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-August/048952.html [2]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-August/048961.html [3]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-August/048963.html [4]FAILED ZTK 1.0dev / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-August/048962.html [5]FAILED winbot / zope.pagetemplate_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-August/048955.html [6]FAILED winbot / ztk_10 py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/048982.html [7]FAILED winbot / ztk_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/048975.html [8]FAILED winbot / ztk_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/048976.html [9]FAILED winbot / ztk_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/048977.html [10] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/048978.html [11] FAILED winbot / ztk_dev py_270_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/048979.html ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, Sep 1, 2011 at 1:28 PM, Chris McDonough wrote:
> On Thu, 2011-09-01 at 09:22 -0400, Jim Fulton wrote:
>> On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough wrote:
>> ...
>> > - zope.testing (for addCleanUp of the global registry in
>> > z.c.globalregistry and other places)
>>
>> This particular detail should simply be cleaned up by
>> moving these calls into tests module.
>
> This is in zope.component.globalregistry at module scope:
>
> base = BaseGlobalComponents('base')
>
> try:
> from zope.testing.cleanup import addCleanUp
> except ImportError:
> pass
> else:
> addCleanUp(lambda: base.__init__('base'))
> del addCleanUp
>
> I didn't see that the registration was conditional on the presence of
> zope.testing last night, but if I understand the intent correctly, it's
> to ensure that importing z.component at all will add a cleanup callback
> to zope.testing such that z.testing.cleanUp() will wipe the global
> registry state. Lots of existing tests will break if this isn't done,
> so I'm not sure that moving it into a place where it isn't executed as a
> side effect is feasible?
I was thinking only of zope.component's tests. There's still the issue of
tests of clients of zope.component, which my suggestion doesn't address.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, 2011-09-01 at 09:22 -0400, Jim Fulton wrote:
> On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough wrote:
> ...
> > - zope.testing (for addCleanUp of the global registry in
> > z.c.globalregistry and other places)
>
> This particular detail should simply be cleaned up by
> moving these calls into tests module.
This is in zope.component.globalregistry at module scope:
base = BaseGlobalComponents('base')
try:
from zope.testing.cleanup import addCleanUp
except ImportError:
pass
else:
addCleanUp(lambda: base.__init__('base'))
del addCleanUp
I didn't see that the registration was conditional on the presence of
zope.testing last night, but if I understand the intent correctly, it's
to ensure that importing z.component at all will add a cleanup callback
to zope.testing such that z.testing.cleanUp() will wipe the global
registry state. Lots of existing tests will break if this isn't done,
so I'm not sure that moving it into a place where it isn't executed as a
side effect is feasible?
- 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough wrote: ... > - zope.testing (for addCleanUp of the global registry in > z.c.globalregistry and other places) This particular detail should simply be cleaned up by moving these calls into tests module. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, 2011-09-01 at 09:15 +0200, Wolfgang Schnerring wrote:
> * Chris McDonough [2011-08-30 03:51]:
> > On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote:
> > My interpretation of your suggestion is that maybe that "zope.component"
> > end up as what "zope.registry" is now. But I don't think preserving the
> > name "zope.component" for this small core and spinning off everything
> > else in the package into separate bits is very attractive, because
> > "zope.component" is just a name and we can do it with a lot less churn
> > and potential for bw incompat if we just rename the core bits rather
> > than changing the meaning of "zope.component" to be "just the core
> > bits".
>
> Yep, that's a fitting assessment.
>
> I have two concerns, the more important one is to establish a clear
> definition of what concepts and functionality constitute the Zope
> Component Architecture (in other words, for the most part, what of
> everything that currently is in zope.component does actually belong
> there?) and to keep these core bits intact when we're extracting
> and/or pruning.
>
> The second one is that the established package name for the ZCA has
> been zope.component, and that I'd rather keep it that way. But I guess
> I'd be willing to concede that point and take up a new name, since I
> agree that trying to keep it probably requires more churn and
> headaches than changing it.
> But I also guess I'd like the new name to be more evocative than
> "zope.registry". Yes, I fully realize the bikesheeding potential, and
> I'm sorry (a little at least ;-), but the ZCA is so much at the core
> of the Zope world I feel it deserves some consideration so as to carry
> a fitting name.
>
> By the way, while we're taking up new names and leaving
> zope.component intact as bw compat, can we use that opportunity to
> clean up the terminology a little? For example, class Components
> should IMHO become class Registry, and getSiteManager could be
> something like getCurrentRegistry.
>
> **
>
> To take up the "what is the ZCA" question again, I don't know if this
> helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael
> Howitz and myself) brainstormed at the office whiteboard and came up
> with stuff the ZCA is used for in Zope3-ish applications:
>
> - Dependency Injection to promote inversion of control (utilities)
> - Multiple dispatch to promote extensibility (adapters)
> - Event handlers to promote decoupling (subscribers)
> - Plain old configuration (any of the above can be bent towards that
> purpose, my "favourite" example being how the default view name is
> handled... ouch.)
> - The notion of a context in which the application runs and that
> informs its behaviour (in Zope3 terms, the "site"; more on that
> below)
>
> These seem to be quite different things, and I'm not certain they
> *should* be all together in one place, but on the other hand,
> extracting zope.registry as proposed seems to me to take out just
> slices of each (think "vertical stripes") and leave other parts of
> each behind in zope.component, which seems to me the wrong way around
> ("horizontal stripes" would be better).
The machinery that makes possible the first three of your "stripes"
above wind up in zope.registry in the current plan, aside from
convenience global APIs. The fourth is a concept that doesn't really
have any code analogue. The last would continue to be provided by
zope.component, at least for Zope, which tends to use the global
registry and various registries encountered during traversal.
> > As far as I'm concerned, the ZCA global API and zope.event machinery are
> > not "guts"; they are convenience APIs on top of the guts. Each promotes
> > the idea that there is a single registry per process, which is not
> > always true (it's not in Pyramid, anyway). I'd be a -1 on seeing these
> > sorts of convenience APIs come along for the ride into the "guts"
> > package, whatever that ends up being.
>
> I don't think zope.component.getSiteManager() promotes a single
> registry per process, but rather (although maybe just as jarring) the
> concept of a "current registry".
>
> While personally I'm not so sure anymore that this is a Good
> Thing(tm), I feel it is quite fundamental to how zope.component is
> used and thought about. If you take this notion away, of a context in
> which code runs and which provides a current registry, no more
> IFoo(bar) and no more simple getUtility, but you'll have to explicitly
> retrieve or pass around the registry.
> (I guess Pyramid does it like that? The registry lives on the request
> and that is passed around throughout the framework?)
Yes, it gets attached to the request. We also make it available via a
threadlocal, but, by default, we don't hook getSiteManager() to make
this possible. Instead we just maintain our own threadlocal registry
and provide an API that allows people to obtain the registry without
having a request in-hand. Using this API
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough [2011-08-30 03:51]:
> On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote:
> My interpretation of your suggestion is that maybe that "zope.component"
> end up as what "zope.registry" is now. But I don't think preserving the
> name "zope.component" for this small core and spinning off everything
> else in the package into separate bits is very attractive, because
> "zope.component" is just a name and we can do it with a lot less churn
> and potential for bw incompat if we just rename the core bits rather
> than changing the meaning of "zope.component" to be "just the core
> bits".
Yep, that's a fitting assessment.
I have two concerns, the more important one is to establish a clear
definition of what concepts and functionality constitute the Zope
Component Architecture (in other words, for the most part, what of
everything that currently is in zope.component does actually belong
there?) and to keep these core bits intact when we're extracting
and/or pruning.
The second one is that the established package name for the ZCA has
been zope.component, and that I'd rather keep it that way. But I guess
I'd be willing to concede that point and take up a new name, since I
agree that trying to keep it probably requires more churn and
headaches than changing it.
But I also guess I'd like the new name to be more evocative than
"zope.registry". Yes, I fully realize the bikesheeding potential, and
I'm sorry (a little at least ;-), but the ZCA is so much at the core
of the Zope world I feel it deserves some consideration so as to carry
a fitting name.
By the way, while we're taking up new names and leaving
zope.component intact as bw compat, can we use that opportunity to
clean up the terminology a little? For example, class Components
should IMHO become class Registry, and getSiteManager could be
something like getCurrentRegistry.
**
To take up the "what is the ZCA" question again, I don't know if this
helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael
Howitz and myself) brainstormed at the office whiteboard and came up
with stuff the ZCA is used for in Zope3-ish applications:
- Dependency Injection to promote inversion of control (utilities)
- Multiple dispatch to promote extensibility (adapters)
- Event handlers to promote decoupling (subscribers)
- Plain old configuration (any of the above can be bent towards that
purpose, my "favourite" example being how the default view name is
handled... ouch.)
- The notion of a context in which the application runs and that
informs its behaviour (in Zope3 terms, the "site"; more on that
below)
These seem to be quite different things, and I'm not certain they
*should* be all together in one place, but on the other hand,
extracting zope.registry as proposed seems to me to take out just
slices of each (think "vertical stripes") and leave other parts of
each behind in zope.component, which seems to me the wrong way around
("horizontal stripes" would be better).
> As far as I'm concerned, the ZCA global API and zope.event machinery are
> not "guts"; they are convenience APIs on top of the guts. Each promotes
> the idea that there is a single registry per process, which is not
> always true (it's not in Pyramid, anyway). I'd be a -1 on seeing these
> sorts of convenience APIs come along for the ride into the "guts"
> package, whatever that ends up being.
I don't think zope.component.getSiteManager() promotes a single
registry per process, but rather (although maybe just as jarring) the
concept of a "current registry".
While personally I'm not so sure anymore that this is a Good
Thing(tm), I feel it is quite fundamental to how zope.component is
used and thought about. If you take this notion away, of a context in
which code runs and which provides a current registry, no more
IFoo(bar) and no more simple getUtility, but you'll have to explicitly
retrieve or pass around the registry.
(I guess Pyramid does it like that? The registry lives on the request
and that is passed around throughout the framework?)
Wolfgang
--
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
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 )
